[ruby-list:49872] Re: Rubyへの要望（願望）

Hi Yukihiro Matsumoto <[e-mail]>, this is MASAKI Yuhsuke<[e-mail]>.
I reply for your mail on Sat, 12 Jul 2014 15:20:37 +0900.

You wrote:
> まつもと ゆきひろです
> 

> continue節はPythonにあるものと同じものを期待してらっしゃるの
> でしょうか。面白いアイディアだと思って昔から考えているのです
> が、難点はRubyの場合、ループなどはブロックを使うことを推奨し
> ており、continue節の導入が正当に意味づけしづらいところです。
> 同様の理由で3 part forも賛成しにくいです。むしろもっとブロッ
> クを使って欲しいところです。
>
whileを使うことはほとんどないのですが、可能であればむしろブロックにcontinue節が欲しいくらいです。
something do
  # main
continue
  # continue
end
さらにいえばこれをやるならば、ブロックにrescueやensureやelseをつけられるようにしてほしいとも思います。

 
> |#文字列の強制エンコーディング処理
> そういうのがあるといいですね。もうちょっと具体化するといいの
> ですが。
> 
lvって割と自動認識してくれるよなー、と思ったのですが、lvはアジア言語に特化しているのですね。
geditの言語認識は予め候補となるエンコーディングを候補順に並べておく必要がありますが、だいたい認識してくれます。ここらへんが妥当な線かな、とは思います。
Teaも同じように対象となるエンコーディングを指定しておくことで自動認識してくれます。恐らくはまた違ったメカニズムだとは思いますが、これもひとつでしょうか。
それぞれの実装について具体的に述べることは（知識不足で）できませんが、
完全な自動化を目指すなら、各エンコーディングの特徴となる部分、
例えば先頭のBOMや、UTF-8の可変長認識のためのバイトルール、エスケープシーケンスなどから「そのエンコーディングの特徴を満たしているか？」を判定、
使用するエンコーディングの優先度をStringのクラス変数に持たせておき、ISO8859のようにそのエンコーディングのバイトルールが競合するものについてはその優先度に基づいて決定。
（より完璧に近づけるならば、単語などでそのエンコーディングに頻出するパターンを照合することで確率の高いエンコーディングをもとめ、
　それとは別にユーザー定義の優先順位を決めるクラス変数を持たせておき、そこで指定されていれば推測された「確率の高いエンコーディング」に代えて
　同様のバイトルールを持つユーザー指定のエンコーディングであると仮定する、というのはどうでしょう）

優先度のアクセサは
String.encoding_priority
String.encoding_priority=
とか。そして、その機能がつけばguessを入れ替えるか、もしくは
String#full_guess
とか。さらには#force_encodeを使いたいのですが、これも名前問題がありそうなので、
String#auto_convert(encode)
でしょうか。


> |#Zsh EXTENDED_GLOBのサポート
 
> ZshのGlob全部はシェルでないRubyでは実現できなかったような記憶
> があります。どこまで欲しいのか、もうちょっと具体的な提案があ
> ると採用しやすいかもしれません。
>
Zsh manualにあるGlob Operator:
  <[x]-[y]> 数値ベースのglob
  (...) グループ化
  x|y OR
  ^x 否定
  x# 1回以上のx
  x## 2回以上のx

と、Glob Qualifierですね。
特に便利なケースとしては、
  **/<->(/n^D)　→カレントディレクトリ以下（再帰）の数値の非ドットディレクトリを数値順ソートで
のようなものです。
 
> |#File#flockにブロックを
> flockはfileがcloseすると解放されるので、
> 
> File.open(path, "r") do |f|
>   f.flock(File::LOCK_EX)
>   # ...
> end
> 
> で十分だと思うのですが。ブロック形式の方が便利なケースを思い
> つきませんが、もしあるということでしたら再提案してください。
>
r+で開いて内容を確認し、内容によって書き込むようなケースですね。例えば
File.open(path, "r+") do |f|
  f.flock(File::LOCK_SH)
  obj = Marshal.load(f)
  f.flock(File::LOCK_UN)
  f.seek(0)
  #...
  if cond
    f.flock(File::LOCK_EX)
    Marshal.dump(obj, f)
    f.flock(File::LOCK_UN)
  end
end

また、このようなことをしないなら、そもそもfileをopenする時点でロックを獲得するような呼び方ができるといいというのもあります。


> |#メソッド名にsymbolを増強
> ちょっと提案の意味がわかりにくいです。
> 
> 「識別子に使える記号を増やして欲しい」という提案であれば、以
> 前にも頂いたことがありますが、正直なところ記号があんまり残っ
> てないです。それにプログラムの読みやすさに貢献しないことが明
> らかなので、あまり積極的になりづらいですね。
> 
> 
実際に遭遇したケースとしては、文字列のエスケープ処理と、文字列のエスケープ処理通過指示(verb)で、
通常のメソッドの形でなくsymbolを使うことでスッキリみせたい、というのがありました。
つまり、
^ "Hello"
のように書きたかったのですが、^インスタンスメソッドを定義した上でinstance_evalを呼んでもself.^を読んでくれないため、そうなりません。
記号が残っていない、というのは感じますが、DSLではもうちょっと書き方に自由度が欲しいな、と思うことがちょくちょくあります。
Ruby組み込みでない（DSL処理スクリプトが処理前に展開する）マクロを書いてしまえばいいのかな、
とは思いますけれど、それもなんだか嬉しくない気がして。

> |# Kernel.syscallにStringを渡せるようにしてほしい
> 「まんま」といわれてもちょっとわからないのですが、syscallでシ
> ステムコールの指定を番号ではなく文字列で指定したいということ
> でしょうか。
>
これも、mkfifoを楽にするために欲しいな、と思ったことですね。おっしゃるとおり、システムコール名で指定したいのです。
他のプラットフォームについて充分に調べられなかったため、syscallを数値で指定すると移植性に影響がでそうだ、と思いまして。
 
> |# next/redo/breakのターゲットを明示できるようにする
> ちょっとよくわかりませんでした。
>
次のようなケースです。

catch :nested do
  a.each do |i1|
    begin
      b.each do |i2|
        case
        when i1.nil?
          throw :nested
        when i2 < 10
          next
        else
          raise
        end
      end
    rescue
      redo
    end
  end
end

breakの代わりにthrow, redoの代わりにraiseを使っています。
このbreakとredoはa.eachに対して行いたい、ということです。
このようなケースで、どこかに処理をいれようとすると同じ処理を複数箇所に書くことになるんだよな、
と思って古いコードを探したのですが、発見できませんでした。ごめんなさい。

> |# IO#write_reopen/IO#read_reopen?
> open3?
>
あ、そうですね…Open3がどういうものだか全く理解していませんでしたm(_ _)m

> |# サブプロセスからの読み戻し
> aliasを使ってはどうでしょうか？ 適切な名前があれば別名をあら
> かじめ用意するのもよいのかもしれません。
>
Kernel.`って文字列しかとりませんよね？argをArrayで渡したいということなのですが…
名称は、ベタにKernel.cmdか、あるいは分かりにくいですけど、Kernel.csubとか？
後半のは、こういうことですね。
str = nil
IO.popen(cmd, "w+") do |io|
  io.write(input)
  io.write_close
  str = io.read
end

 
> |# 先進的演算子

> |.=
> こういうのが欲しいのはわかりますが、この記法はあまりよくない
> ように思います。
>
では、パーサが大変になりそうですが、
obj ->method(arg)
かぶりをさけるなら
obj <-method(arg)
のほうがマシでしょうか。
 
> |# 軽量な起動, precompile
> Emacsでもそうですが、最近マシンが高速化していてそういう対処
> は不要になってきているようです。起動時間のかかるJRubyならと
> もかく、CRubyでそこまで必要なケースはかなり少なくなっている
> とおもうのですが、なにか事情があるのでしょうか。
手元で起こっているケースとしては、シェルスクリプトで一部処理でRubyを使うものにしています。
シェルスクリプトの1回のループで行われるRubyスクリプトの実行は5回です。
大体1回で3万ファイル程度を対象にするため、15万回Rubyを起動し、スクリプトをコンパイルすることになります。
この場合スクリプトが非常に小さいため、ほとんどはforkのコストですが、なんだか同じ内容をコンパイルばっかりして無駄な気がします。

また、webappでは応答性が重視されると思うのですが、fast_cgiやmod_rubyなどでRubyインスタンスは常駐している状態だと、
変更されるわけでもないのにくりかえしよばれるスクリプトが毎回parseしてcompileして、という過程を経るのは非常に無駄な気がします。
特にトラディショナルなchatのように極めて頻繁に呼ばれるケースでは実行回数が非常に大きくなり、
トータルの実行時間が長くなる上にその時間で実処理時間が占める割合は相当に低くなります。

もちろん、ソケットを使うなど実行モデル自体の見直しによって改善すればよい話なのですが、
書き直しの頻度に対して実行数が極めて多い場合は事前にできるだけのことをやっておきたいな、と。
実際の運用でスクリプト実行開始までの時間が問題になる印象をRubyで受けたことはないのですが、
WordPressの応答性の悪さなどを考えると、応答時間に影響する部分は可能な限りつめたほうがよいように思えるのです。


###
ひとつ抜けていたので追加させてください。

#Object.remove_module
prependがあるのならば、モジュールを外すことができれば、一時的にメソッドを書き換えるようなことは
スマートかつ容易に行えるように思えます。

================================
# The Rider, Hacker and Musician
#    ENABLE YOUR HEART.
#
#  mailto:[e-mail]
# Blog: http://reasonset.net/journal/
# Twitter @reasonset
=================================