あまり好まれない AI によって作成されたコードを分析しました。
dt = Open("$SAMPLE_DATA/Big Class.jmp");
kd = dt << KDTable("hello");
result = kd << K Nearest Rows(1, 3);<BR />print("finished");
ログにはこう記されていた。
Object 'Data Table' does not recognize the message 'K Nearest Rows'; perhaps you mean one of these: <
<<<<<<<<
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 ...
JMPはこのように設計されています。私も違う方法があればいいのにと思っています。この設計上の理由は、(1) オブジェクトが理解できないメッセージを無視すること、(2) メッセージを連鎖させることができることです。以前のリリースでは、JMPの一部のオブジェクトが認識できないメッセージを報告するように設定されていました。これが機能するかどうかはオブジェクトによって異なります。おそらく、すべての表示ボックスには、この問題に対処するための共通のコードが備わっているのでしょう。
tb<のようなメッセージの連鎖
これらのルールによれば、例の 2 行目は期待どおりの動作を行います。
認識されないメッセージを黙って無視する機能は、おそらくMS-Windowsのメッセージ処理（前世紀）を研究した結果生まれたものだと思います。黙って無視されるメッセージは驚くほど多くあります（マウスがあなたの上に動いているのに、マウスに反応するつもりがないなど）。JMPでは、次のように使用できます。{ textBox, outlineBox } << setcolor("red") << close(1); リスト内の< <<>
例がデータテーブルに送信する2つのメッセージの違いは、 kdテーブル()はグローバルなプラットフォームのような関数であるのに対し、< < m> kdtableオブジェクトのみが認識するメッセージです。データテーブル自体は、プラットフォームの起動、 dt<のようなメッセージを受け取るのが好きです。 例えば、ここにバグがあります。kdtableが「hello」引数に関する問題を報告していないため、データテーブルがプラットフォームが起動されたと認識している可能性があります。もしかしたら、空のプラットフォームかもしれません（申し訳ありませんが、そんなものは存在しません）。
kdtable("hello")
/*:
Empty()
こんにちは
@Craige_Hales 、詳細な背景をありがとうございます。確かに、当時 JSL がこのように設計された
理由は理解できます (不明なメッセージを黙って無視 + 左側のオブジェクトを返す連鎖)。
しかし、私はまた、JSL 開発者がこのパターンが今日の AI 支援によるバイブコーディングと多少「互換性がない」ことに気付くことを願っています。
LLMはメッセージ、プラットフォーム呼び出し、引数を喜んで作り出しますが、現状ではそれらはしばしば黙って無視されてしまいます。これは混乱を招くだけでなく、デバッグを地獄に変えてしまう可能性もあります。根本原因ではなく、症状の追及に追われることになるのです。
おそらく、開発者は「AI デバッグ / チャッティ モード」用の JSL レベルのスイッチを提供できるでしょう。
選択したオブジェクト クラス (表示オブジェクト、プラットフォーム、一般的なスクリプト可能オブジェクトなど) に対して、ノイズは多いが非常に役立つ診断を意図的にオンにします。
最終結果がおかしく見える場合、このモードを有効にすると、JMPは静かに失敗してずっと後になってから警告するのではなく、最初に軌道から外れた箇所を正確に報告し始めます。この項目を投票のためにウィッシュリストに追加しました：
AIデバッグ用のチャッティモード（）
貴重なご意見と、これが行動改善の余地がある領域であることを確認してくださったことに改めて感謝いたします。
