«前の日記(2007-02-18) 最新 次の日記(2007-02-20)» 編集

Matzにっき


2007-02-19 [長年日記]

_ 人間は眠れないのが本来の姿、という話

もともと近代以前は夜はとても危険で、 おちおち眠れなかった、という話。

だから、少々眠れない、眠りが浅いくらいがむしろ普通、と。

そういえば、聖書とかでもよく「一晩中」とか「朝になるまで」とかいう エピソードがあるよな。昔はしょっちゅう徹夜していたということか。

じゃあ、現代でも少々徹夜くらいはどうということはない、のか?

_ ウェブが創る新しい郷土 地域情報化のすすめ

書評。

ITを活かした新しい地域活性化。 松江市もきっとそういうのを目指しているに違いない。

こどもの安全の確保、引退者の大量出現への対応という時代の要請と、ITという道具の普及が変化をもたらした。新しい地域活性化の試みがこの本にはたくさん紹介されている。たとえば地域SNSが次々につくられて数千人規模にまで成長したケース。誰もが講師になれる生涯学習プログラムの熱気。NPO法人が情報化の仕事を受注し地域コミュニティ内のSOHOが請け負う仕組みで事業を創出したケースなど。成功例または成功の兆しがたくさん解説されていた。

地域は信頼性の高い情報プラットフォームになる可能性を秘めている。国領二郎慶応大学教授の意見が引用されている。

「外部効果の強い、つまり貢献に対するリターンが外部に流出しやすく、参加の貢献のインセンティブが弱くなりやすいネット上の情報共有も、地域(物理的近接)のバインドのなかであればメリットを可視化、内部化しやすく、持続可能な誘因と貢献のモデルを構築しやすい」

住みやすく、働きやすく、かつ、特色ある地方をITで。

_ 3月24日は『SHUTDOWN DAY!』

3月24日はShutdown DayとしてPCの電気を切って過ごしましょうという提案。

普段、自宅にいる間はこたつの上にPCを置いているわけだが(で、向かいには妻のPCがある)、最近、こたつの上にメモが貼ってある。

日曜日はノーパソコンデー!!

というわけで、日曜日にPCをいじってたりすると 妻ににらまれるということで。

まあ、週に一度くらいPCを離れることは 家族の団らんやら、精神性の重視という点から有効かもしれない。

〆切直前だったりすると、ちと焦るんだけど。

_ u1hoshinoの日記 - Protocol Buffers

複数言語間で通信を行うチャネル...なのかな。

面白そうだが、詳細を調べてる時間(または、精神的余裕)がない。 後で。

_ [Ruby] On Ruby: Serial XRuby Interview: Episode I

Serial Interviewシリーズ。XRuby開発者編。

XRubyを作ってる人たちって中国人なんだねえ(アメリカ在住を含む)。 中国人によって開発されているオープンソースソフトウェアって あんまり知らないから(中国固有のソフトを除けばscimとstardictくらい?)、 そういう意味でも興味深い。

_ [Ruby] 404 Blog Not Found:ruby - var := 1 って my $var = 1; のこと?

弾さんによる「:=」へのツッコミ。

Rubyのsigilは(Perlと違って)スコープを表すのに面食らう

Perl出身の弾さんゆえ、Perlに親しんでおられるのはわかるが、 近代的言語においてsigilを採用するのであれば、 その示すべきものは絶対にデータタイプではない。 データタイプを表現するsigilなんてのは ユーザ定義データタイプを持たない旧式言語の名残でしかない。

Perlでさえ、Perl5以降はリファレンスの導入により ほとんどすべてのものをスカラで表現できるようになったので、 旧来のデータタイプsigilの役割はずいぶん下がっている。

myやvarを採用した方がRuby as Second Languageなユーザに優しい

myはともかくとして、varというのはひとつの有効な案であるとは認める。 しかし、互換性の観点からは、予約語を増やすことの弊害の方が大きいと考える。 とはいえ、ローカル変数のルールを変えてしまう時点で互換性も何もあったもんじゃないんだが。

それに明示的な「宣言」を避けるってのがRuby流だしね。

「:=」はPerl6でbinding operatorである
正直、Perl6(特に新しく導入された演算子)のことは知らんがな、という感じである。 いったいいくつあるんだか。優先順位レベルだけは少なくなってるらしいが。
「|foo|=1」はどうか
残念ながらブロックパラメータと重なる(文法的に矛盾する)ので、 採用できそうにない。それに醜いよ、いくらなんでも。

また、PoLSに言及しているのも減点。

Rubyに対する提案のうち、PoLSに言及したものの優先度は自動的に下がることに なっている。(私じゃない)誰かが自分のバックグラウンドと異なるという理由で どれだけ驚いても責任は持てない。 むしろ、PoLSへの言及を含む提案は 主観的な「私の思い通りじゃなきゃイヤ」という暗黙の主張を含んでいることが多く(弾さんがそうだって言ってるわけじゃないけど)、とにかく扱いにくいから。

本日のツッコミ(全28件) [ツッコミを入れる]
_ Gimite (2007-02-25 10:33)

var a= 1は「明示的な宣言」でa:= 1は「明示的な宣言ではない」というのがよく分からないのですが…。明示的な宣言といえる条件は何なのでしょうか?予約語を使っていること?

_ (2007-02-25 12:03)

個人的に、「明示的な宣言」ができないことだけがRubyの文法上の唯一の欠点だと思っている(「俺は、この変数を、ここで初めて使う!!」と言う意志を表せない)ので、「var」あるいはそれに類するものの導入は大賛成なのですが……。<br>他言語からの類推を除外しても、a := 1 ではその意志は理解し難いと思います。

_ 野分 (2007-02-25 14:11)

既にあるインスタンス変数とクラス変数のルールと合わせられるといいんですけどね。メソッドスコープの変数。<br><br>他のリテラルとバッティングしないようにするには<br>$@var, @$var, $$var, @@@varとかしか無いですかね……<br><br>_単独のメソッドは普通作らないと仮定するなら、<br>_@varなんかもありですね。

_ (2007-02-25 17:31)

余談ですが := って数学では、数式の中で使われる"文字"の意味を定義するのによく使われますよね。

_ BASICって意外といけてたよ (2007-02-25 20:22)

暗黙のうちに同じシンボルが2つの値を持つことは不明瞭さを生むと思います。どんな言語でどんな表記を採用してもそれは解消されないのではないでしょうか。明示的な宣言は「注意せよ」という意味で役に立ちますがruby風ではないですよね。それに中途半端です。できれば今のままの方が単純明快で気持ちがいいなと思います。

_ えとー (2007-02-26 00:02)

ノーパソデーならノートパソコンはOKなんですね。<br>そうですね。<br><br>つまり普段通りと。

_ mrkn (2007-02-26 01:18)

「:=」とは全く関係無い話なんですが,Haskell や R のように,2引数のメソッドを2項演算子化できる記法を導入しませんか?<br>Haskell が使ってる ` や R が使っている % はもう使えませんが,何とか他に余ってる記号があるはずです!<br>今のところ,良い記号の候補は見付かっていませんが(汗;

_ mrkn (2007-02-26 01:23)

submit した直後に気付きましたが,良く考えてみると,2項演算子化する記法は Ruby には不要ですね(^^; それが役に立つコンテキストは Ruby にはありませんよね.お騒がせ致しました.

_ M.Suzuki (2007-02-27 14:29)

変数のスコープと言うのは階層化したツリーで表せるものなので、そのツリーをファイル構造に見立てれば、<br>@..var,$..var,..var で、限定的に階層を抜け出せるとか・・・。<br># でも、$varがスレッドローカルで<br># $..varがスレッドグローバルとか使い勝手悪すぎ<br><br>言語の論理として美しくても書式が美しくないのは受け入れがたいですからね。。。

_ g-squid (2007-02-27 15:23)

var だと代入なしの定義(== 宣言)ができますが、それってRubyにこれまで存在しない概念なのでは?<br>その点 := だと変数の定義は代入のみというルールは変わらないですみますね。

_ 野分 (2007-02-27 20:50)

:=も「代入操作でスコープが決まる」ということで、Rubyでは今まで採用していなかった概念かと思います。<br><br>従来は命名規則でスコープを決定していましたね。@とか@@とか$とか。<br><br>メソッドスコープもそれに合わせられるとキレイ&見やすいのですが……

_ まつもと (2007-02-28 00:22)

Rubyは昔から代入でローカル変数のスコープが決まってました。<br>今回でそれが「はっきり目に見える」ようにしたわけです。

_ g-squid (2007-02-28 00:47)

スコープの種類ではなくて、スコープがネストしたときにどのスコープを選ぶかという問題なので、命名規則(これはスコープの種類を決定する)で解決する必要はないと思います。<br><br>スコープのネストはローカルスコープでなくても起こるので(例:クラス変数)、命名規則とはまったく別の規則を使ったほうがかえってすっきりしそうです。

_ 野分 (2007-02-28 00:56)

おっと、すみません。スコープと変数の種類の話がごっちゃになっていました。所属するスコープは代入する位置で決まりますね。<br><br>このへんを見直して思ったのですが、<br>http://www.rubyist.net/~matz/20070112.html#p04<br><br>・デフォルトはスコープローカル変数<br>・「:=」で代入した変数はブロックローカル変数<br><br>というルールよりも、<br><br>・デフォルトはブロックローカル変数(従来通り)<br>・$@var(または@$var/$$var/@@@var)でスコープローカル変数<br><br>という風なルールの方が、命名規則で変数の種類を区別しているrubyに沿った&影響の少ないルールになるかと思います。

_ まつもと (2007-02-28 01:19)

えーと、まず、なにをもって「影響が少ない」としているかがよく分かりません。<br>スコープローカル変数にprefixを付けたら影響は甚大だと思いますが。<br><br>さらに個人的にはブロックローカル変数よりもスコープローカル変数の方が<br><br> * 分かりやすい<br> * 使いやすい<br><br>と思っているので、prefixを付けて、醜く使いにくくする理由がありません。<br>さらに言えば、ブロックローカルとそうでないものも、結局は両方ともローカル変数なので、明示的に区別する動機さえありません。<br><br>「:=」を付けるのは変数種別を指定したいわけではなくて、同じローカル変数の中で有効範囲を指定したいんです。

_ 野分 (2007-02-28 01:50)

なんか疑似問題になっているような……<br><br>まずは確認ですが、<br><br>・ブロックローカル変数<br> - 従来のローカル変数と同じ挙動をする変数<br> - ブロック内で初めて代入:ブロック内のみ有効<br> - スコープで初めて代入: スコープ内で有効<br><br>・スコープローカル変数<br> - 新しく定義しようとしている変数(の種類)<br> - ブロック内で初めて代入:スコープ内で有効<br> - スコープで初めて代入: スコープ内で有効<br><br>ということで良いですか?<br>結局のところ変数の挙動が変わるので、「同じローカル変数」とするよりも「二種類のローカル変数」とした方が分りやすいかと思います。<br><br><br>今回の話の中心は、従来のローカル変数(ブロックローカル変数)に加えて、新たにスコープローカル変数を定義しようとしていることかと考えています。<br><br>matzさんの案ですと、<br><br>1. ローカル変数の挙動を、「スコープローカル変数」に変更する<br>2. 「ブロックローカル変数」を指定するには operator:=を使用する<br><br>ということかと思いますが、これは<br><br>1. ローカル変数はそのまま「スコープローカル変数」相当と<br>  なるため、従来の「ブロックローカル変数」相当の<br>  挙動から変更になる<br>2. 変数の種類の指定をoperator:=で指定<br> -> 従来の「変数の種類を命名規則で指定する」という<br> ルールに従っていない<br><br>という変更になるかと考えています。<br><br><br>私の案もあまり良くは無いですが、それでも<br><br>1. ローカル変数はそのまま(従来の)「ブロックローカル変数」になる<br>2. 変数の種類はprefixで指定<br> -> 従来の「変数の種類を命名規則で指定する」に準拠<br><br>となるため、matzさんの案よりも影響は小さいと考えています。<br><br>どうですかね?

_ まつもと (2007-02-28 03:59)

おっしゃるように「スコープローカル変数」は新しいものだと言う捉え方をすればそうなるんでしょうね。<br><br>ただ、私自身は「分けた方がよい」とはまったく考えていません。<br>分けることによるメリットよりもデメリットの方が大きいのではないでしょうか。<br><br>メリット<br><br>* 違う種類の変数(と見なせないこともない)ものが区別できる<br><br>デメリット<br><br>* より使いやすい(と私が感じる)方が醜い<br>* 似たような変数が複数導入される<br><br>私にとってはデメリットはどちらも妥協不能なくらい大きいものです。

_ loyaltouch (2007-02-28 15:44)

->のときもそうでしたが、意味のわかりづらい記号をRubyに増やすのはPerlの特殊変数を排除したい最近の流れに反するのではないでしょうか?<br><br>この手の話が出るたびにMatzさんが予約語が増えることを恐れているらしき様が見えてきますが、せっかくメジャーバージョンアップするんだしそこらへんは気にせずいきましょうよ。

_ oo (2007-02-28 17:41)

議論ポイントは、<br><br>大前提:<br>ブロック内で初めて登場するローカル変数であってもデフォルトはスコープローカルに挙動を変更する<br><br>課題:<br>ブロック内のみの名前有効範囲を持つローカル変数をどのようにして上記のローカル変数と区別するか<br><br>ですよね。<br>(案1) := で代入<br>(案2) 宣言する (var とか local とか let とか)<br>(案3) 先頭の記号で区別 (ピリオドはどうでしょう?)<br>・・・<br><br>これらと別に大前提に対しての反対案(今のまま)がある。

_ 野分 (2007-02-28 23:49)

>matzさん<br>> * より使いやすい(と私が感じる)方が醜い<br>> * 似たような変数が複数導入される<br><br>そもそもブロックローカル変数を用意する必要性はほとんど無いのでは?<br><br>http://www.rubyist.net/~matz/20070112.html#p04<br>> 現状のRubyでは、ブロックの中で初出のローカル変数の有効範囲はそのブロックの中に限定される。これは無名関数のようにブロックが使われる時にその関数の中だけで有効なローカル変数が使えないと非常に不自由だからだ。<br><br>と言っていますが、:=演算子というrubyに無かった概念(しかもこの対応限定)を導入してまで解決するほど重要な問題なんですかね?<br><br>http://www.ruby-lang.org/ja/man/?cmd=view;name=%A4%CF%A4%B8%A4%E1%A4%CB<br>に謳つているコンセプトに従うのならば、こんな微妙な違いを残さないほうが良いと思います。<br><br><br><br>また、<br><br>> * より使いやすい(と私が感じる)方が醜い<br><br>もちろん<br>ブロックローカル変数: @$などのprefix表記<br>スコープローカル変数: 従来の変数表記<br>もありだと思います。<br>#従来のルールに手を入れるのであんまり好きでは無いですが。

_ Gimite (2007-03-01 11:23)

http://www.rubyist.net/~matz/20070219.html#c15<br>にもありますが、「変数の種類をprefixで指定」する方法は<br>def hoge<br> a= 0<br> foo do<br> a:= 1<br> bar do<br> a:= 2<br> p a #=> 2<br> end<br> p a #=> 1<br> end<br> p a #=> 0<br>end<br>のようなケースをうまく表現できないと思います。無理やりやるならこんな感じでしょうか:<br>def hoge<br> a= 0<br> foo do<br> @$a= 1<br> bar do<br> @$$a= 2<br> p @$$a #=> 2<br> end<br> p @$a #=> 1<br> end<br> p a #=> 0<br>end

_ Gimite (2007-03-01 11:30)

ところで「投稿」ボタンを押すと毎回<br> 500 Internal Server Error<br> timeout (15 sec) (Apache::TimeoutError)<br>が出る(が、投稿はされている)のは僕だけでしょうか。

_ まつもと (2007-03-01 11:38)

野分さんへ、<br><br>>そもそもブロックローカル変数を用意する必要性はほとんど無いのでは? <br><br>野分さんのおっしゃる「スコープローカル変数」があればたいていの用事が足りるという点には同意します。ただし、「じゃあ、なくてもよい」とはいきません。<br>lambdaで局所的なローカル関数を作ったりするケースで、その「関数」に固有の変数が存在できないと言うのでは、絶対に書けないプログラムが出てきてしまいますから。<br><br>「まれかもしれないが必要な機能」に「普段必要な機能」よりも長くなる記法を用いるのは当然だと思います。具体的には「=」と「:=」なわけですが。<br><br>で、「微妙な違い」についてですが、微妙だと感じるのは<br><br> * ブロックローカル変数とスコープローカル変数を分離している<br> * 今回改めてRubyのローカルスコープルールに注目した<br><br>からではないかと推察します。もともとやたら複雑だったのを、実際のユースケースに合わせて単純化(ローカル変数のデフォルトスコープを「スコープローカルに」)したと考えていただけるとよいと思います。

_ まつもと (2007-03-01 11:44)

Gimiteさん、<br>500 Internal Server Error <br>の件ですが、私もしょっちゅうくらっています(4回に3回くらい)。<br>ホストの負荷が高いせいなのかなあ。

_ 野分 (2007-03-02 01:08)

>matzさん<br><br>そうすると、<br>・「ブロックローカル変数」でないと実装できない機能がある(かもしれない)<br> ので、「スコープローカル変数」に統一することはできない<br>・「ブロックローカル変数」と「スコープローカル変数」の違いは、変数タイプの<br> 違いとして考えるほどではない<br> (変数の命名規則に取り入れるほど大袈裟な話ではない)<br> -> :=演算子を新たに導入して所属するブロックを明示するようにした<br><br>といった感じですか。<br><br>個人的には『変数の命名規則(従来のrubyのルール)で解決できるのに、わざわざ :=演算子を導入することは無いんじゃないか』と考えてしまうところですが……<br><br><br>> Gimiteさん<br><br>prefixで決めるのは「どのスコープ・ブロックに所属するか」ということではなく、あくまで「ブロックローカル変数とスコープローカル変数のどちらなのか」ということですので、:=演算子とやっていることは同じですね。<br>変数名に明示されるかどうかという違いはありますが。<br><br>def hoge<br> a = 10<br> @$a= 0<br> foo do<br> @$a = 1<br> bar do<br> @$a = 2<br> p @$a #=> 2<br> end<br> p @$a #=> 1<br> end<br> p @$a #=> 0<br> p a #=> 10<br>end

_ まつもと (2007-03-02 01:20)

野分さん、<br>『変数の命名規則(従来のrubyのルール)で解決できる』のは確かですが、その方が望ましいのは(野分さんが当初考えておられたように)、「スコープローカル変数」と「ブロックローカル変数」が(少々似てはいても)違う種別の変数であるととらえる場合において、ですよね。<br><br>実際に私が提示したいモデルはそれとは違っていて、「ローカル変数には一つの種別しか無く、各変数にはそれぞれ所属するスコープがある。デフォルトはdef/class/moduleで導入されるスコープ」というものです。これには「スコープローカル変数」と「ブロックローカル変数」の区別は無く、よって命名規則によって解決できるものではなくなります。

_ Gimite (2007-03-02 11:27)

>野分さん<br>その書き方ですと今度は<br>def hoge<br> a= 0<br> foo do<br> a:= 1<br> bar do<br> a= 2<br> p a #=> 2<br> end<br> p a #=> 2 ←!<br> end<br> p a #=> 0<br>end<br>が表現できないと思いますが…。

_ 野分 (2007-03-02 23:59)

>matzさん<br>このあたりは好みの違いですかね。<br>下記でGimiteさんが指摘しているように、:=演算子の方が(新しいルールを導入しているので)表現力が高くなっていますけど。<br><br>>Gimiteさん<br>確かにそうですね。:=演算子による操作ではなく命名で挙動を制御している限り、ここは回避できないですね。<br>……こんな微妙なコード書かずにもっと注意して命名すべきだとは思いますが。<br><br>#よくよく考えると(2007-03-02 01:08)が間違ってますね……

お名前:
E-mail:
コメント:
[]

«前の日記(2007-02-18) 最新 次の日記(2007-02-20)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.