AI scripting - misleading log ...

Question

I just analyzed a code created by a less favorite AI:

dt = Open("$SAMPLE_DATA/Big Class.jmp");
kd = dt << KDTable("hello");
result = kd << K Nearest Rows(1, 3);<BR />print("finished");

The log said:

Object 'Data Table' does not recognize the message 'K Nearest Rows'; perhaps you mean one of these:  <<Insert Rows <<Delete Rows <<Select Rows <<Select All Rows <<Get Labeled Rows <<Get Hidden Rows <<Get Excluded Rows <<Clear Cell Colors <<Make Indicator Columns... <<Get as Matrix <<Get As Report <<Get Row States <<Get Rows Where <<Get Selected Rows <<Clear Edit Lock <<Make SAS DATA Step <<Make SAS DATA Step Window <<New Data View <<New Data Box <<Markers <<Go to Row… <<Invert Row Selection <<Select Duplicate Rows <<Clear Row States <<Clear Selected Row States <<Add Rows… <<Get Rows <<Move Rows… <<Clear Sel

finished

Sure: if a scriptable object doesn't understand a message, it shows such a warning message in the log.
And a Data Table doesn't understand the the message K nearest Rows().

But wait, why is kd a data table?!
This is easy to answer: In the previous line of code, the data table doesn't understand the command << KDTable("hello");

And therefore, instead of returning a KD table, it returns a reference to itself.
Unfortunately, here is NO warning message:

Object 'Data Table' does not recognize the message 'KD Table("hello")'

A JSL scripter will spot the error within seconds :  KD Table("hello") , tztztz!
But you’d probably agree—it’s hard to find the error from the information JMP provides!

How to escape this issue?  Is there a general rule or trick?
Can JMP / the JSL interpreter be improved to help AI and the users understand the errors?

Users with paranoia could add  If (type(name Expr(returned object) == ...) after every message sent to a scriptable object. Hm ...

hogi · Answer

Hi @Craige_Hales , thanks a lot for the detailed background – Sure, I can understand why JSL was designed this way back then (silent ignore of unknown messages + chaining returning the left‑hand object).
 
However, I also hope that the JSL developers see that this pattern has become somewhat “incompatible” with today’s AI‑assisted vibe coding:
LLMs happily invent messages, platform calls and arguments, and with the current behavior they often just get silently ignored. That doesn’t only confuse, it can also turn debugging into pure hell – you end up hunting the symptom instead of the root cause.
 
 
Maybe, developers can provide a JSL‑level switch for “AI debug / chatty mode” :

chatty mode();

to deliberately turn on noisy, but incredibly helpful diagnostics for selected object classes (e.g. display objects, platforms, general scriptable objects).
 
The idea is that when the end result looks weird, you enable this mode and JMP starts complaining exactly where things first go off the rails, instead of failing quietly and only shouting much later. I’ve put this into a Wish List item here for voting:chatty mode() for AI debugging 
 
Thanks again for the insights and for confirming that this is an area where behavior could be improved.

Craige_Hales · Answer

JMP is designed this way. I also wish it was different. The parts of the design that make this happen are (1) objects ignore messages they don't understand and (2) messages can be chained. Many releases ago JMP added a preference to make some objects report unrecognized messages. Whether it works depends on the object; I think the display boxes all have some common code to deal with it.

Chaining messages, like tb<<settext("hi")<<setcolor("red") is also allowed. The result of each << operator is the left side object. That means you can't get a grandparent with tb<<parent<<parent; you have to use (tb<<parent)<<parent.

By those rules, line 2 of your example does what it is supposed to.

I think the silently ignore unrecognized messages probably originated from studying the MS-windows message handling (previous century); there are an incredible number of messages that are silently ignored (like the mouse is moving over you, but you have no intention of ever responding to the mouse.) In JMP it could be used like this: { textBox, outlineBox } << setcolor("red") << close(1); where any box in the list that understands <<setcolor or <<close does the operation.

The difference between the two messages your examples sends to the data table is kdtable() is a global platform-like function while <<kNearestRows is a message that is only known to a kdtable object. The datatable itself likes to see messages that look like platform launches, dt<<distribution(...) for example. There is a bug here. I suspect kdtable is at fault for not reporting an issue with the "hello" argument, and the data table may think a platform was launched. Maybe the empty platform (sorry, there is no such thing.)

kdtable("hello")
/*:

Empty()