FINEARCHS

関数の`==`は配列・オブジェクト同様、JavaScriptの等号による比較でよさそうですかね

空白・改行による区切りの再検討もそうですかね？

ユースケースによってはシード値の保存とかをしている可能性がある以上、乱数生成・調整アルゴリズムの変更は破壊的変更ということになりそうですかね？ ユーザー側で手法を選べるようにするか、そうでなければnext（破壊的変更用ブランチ）に入れるのがよさそう？

`Json:parse`がエラー型を返すようになったのでいつか`Json:parsable`を廃止しようと思っていたのですが、このタイミングでいいですかね？

配列の長さに制限をつけたほうがよさそうですかね？

論文を読むのがかなり苦手なのであまり参加できないかも…

`Json:parsable`でチェックしてから`Json:parse`すると単純に考えて倍の時間がかかるので非推奨にしたいんですよね 非推奨にしても残すと使い続ける人がいると思うので出来れば消したいです。

構文案 ```js catch(v) {...} // if Core:type(v)=='error' {...}に同等 ```

うーん、話を聞く限りよほど大きい数を扱わなければ分布の偏りは無視できる程度に収まりそうですかね？ 大きな数向けのより高精度な乱数や、より予測しづらく暗号に使えるような乱数は別の関数として実装するのがいい気がします

この先更に精度が良かったり安全だったりなアルゴリズムを実装する時の対応を考えたいですね… 例えば、`Rnd:rejection_sampling`や`Rnd:lemires`のようにアルゴリズムが識別できるような命名の関数をいくつか用意して、 それらのうち、例えば - 動作の軽い乱数の最新版を`Math:rnd` - 精度のよい乱数の最新版を`Math:rnd_fine` - 予測しづらい乱数の最新版を`Math:rnd_safe` というようにエイリアスを用意することで、多くのユーザーにはより改善されたアルゴリズムを提供でき、アルゴリズム変更が気になるユーザーにも以前のアルゴリズムを使い続ける選択肢がある、というのはどうでしょうか？