ToDo:
SADでは、構文解析時に引数が確定している関数言語的な意味で 純粋な組み込み関数に関しては、構文解析時に評価してしまうという という仕様である。たとえば、
In[1]:= Hold[Plus[1, 1]] Out[1]:= Hold[2]
のように評価される。
このルールの元では、Slot演算子に対しても中身は確定していないが 1個の Atomであることは確定しているものとして扱うので、 組み込み関数Lengthの引数となるリストの要素として現れたときに 実引数と結合可能かどうかを問わずに評価されてしまう。
しかし、Slot演算子では、 純粋な関数を字句的に展開した式と展開前の式の評価値が異なる
f = {#1, #2, #3, #4}&;
g = Length[#]&;
fg0 = g[f[##]]&;
fg1 = Length[{#1, #2, #3, #4}]&;
Print["fg0 -> ", fg0[1,2]];
???General::slot: Undefined Slot #3 in ({#,#2,#3,#4}&)[1,2]
???General::abort: Aborted:
Print["fg0 -> ", fg0[1,2]]
^
???-FFS-Error-?Undefined command or element: PRINT["fg0
Print["fg1 -> ", fg1[1,2]];
fg1 -> 4
のような例題が存在できる。 この例では、実行時に純関数(Function)を実引数と結合する際に 仮引数と数が釣り合わない例外が発生しなくなっている。
上記の例題では、例外が発生しているので、評価結果の唯一性が保証 されなくともよいという考え方があるが、次のUnevaluatedを用いた例題では Nullを頭部とする未評価のS式を送り込むという正常系の動作である。
f = {#1}&;
g = Length[#]&;
fg0 = g[f[##]]&;
fg1 = Length[{#1}]&;
Print["fg0 -> ", fg0[Unevaluated$[Unevaluated$[Null[a, b, c]]]]];
fg0 -> 3
Print["fg1 -> ", fg1[Unevaluated$[Unevaluated$[Null[a, b, c]]]]];
fg1 -> 1
以上の考察から、Slot演算子が1個の確定したAtomであるとして評価を最適化 するのは結構邪悪な実装だと思われる。
数日前にglib-2.80.3へのアップデートでlibreoffice起動問題が修正されたが、終了時にトラブル件だが、 libreoffice側の起動不良が繰り替えされた環境で生じる問題かも知れない…
FV5セットアップの過程で判明した、現時点のOut of BoxなFreeBSD 14.1-STABLEでサポート不足なもの纏め
各種パッチを当てた状態での実用上の問題は、以下の通り
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記