Remove From（）関数が意図したとおりに機能していないことに気付きました（そして、そのドキュメントはScripting IndexとJMPヘルプの両方で間違って書かれています）。 最後の要素がリストから削除されると、不合理に動作するようです。
これについてJMPサポートに連絡しました。 彼らによると、意図された動作は次のとおりです（私が期待するのと同じです）：
予想される動作は、最初の9つのアイテムについて例が示すように、RemoveFromが削除されたアイテムを返すことです。さらに、アイテムを削除することで入力コンテナを変更します。
これが修正され、ドキュメントが更新されるタイムラインについて彼らが知っているかどうか、私はまだ彼らから返事をもらっていません。 タイムラインで返信があれば、ここに報告します。
例と1つの「回避策」（削除元と同じ動作が本当に必要な場合は、今のところ独自の関数を作成します）：
Names Default To Here(1);
m = 1::10;
For Each({item}, m,
earlier_m = m;
// Returns: The original source with the items deleted.
// Doesn't this return deleted list (except when it is last element...)
removed = Remove From(m, 1);
Print(Eval Insert("^removed^ removed from ^earlier_m^"));
);
// workaround?
m = 1::10;
For Each({item}, m,
earlier_m = m;
removed = m[1];
Remove From(m, 1);
Print(Eval Insert("^removed^ removed from ^earlier_m^"));
);
これを報告していただきありがとうございます。このバグは、ベクター（行列）で使用されるRemoveFrom（）の呼び出しに適用され、リストコンテナーには適用されないことに注意してください。
あなたの回避策はベクトルにとって合理的であるように思われます。リストでこの回避策を使用する場合は、最初の要素のコピーを作成することに注意してください。ほとんどのタイプでは、これで問題ありません。表示ボックス、データテーブル、またはプラットフォームを参照する要素をコピーすると、同じオブジェクトを参照する別のシンボルが作成されます。リスト要素に大きな行列や連想配列などの項目が含まれている場合は、このオブジェクトの複製コピーを作成します。これも大きな目立った効果はないかもしれませんが、回避策のセマンティクスはわずかに異なります。
