ときどきの雑記帖 めぐりあい電脳空間編

最新ページへのリンク
目次ページへのリンク

一つ前へ 2010年6月(中旬)
一つ後へ 2010年7月(上旬)

ホームへ

2010年06月30日

■_

・今月の皇帝陛下
いよいよかな。

・そばもん
四巻出てた。

■_

「ソースコード」がないのに「ソースコードを解析」とは?


作者不詳のプログラムのソースコードを解析する手段はないでしょうか? - Yahoo!知恵袋

作者不詳のプログラムのソースコードを解析する手段はないでしょうか?

社内のとあるシステムの一部分のプログラムなのですが突然エラーを起こすようになりました。
これがまたやっかいでユーザーへの悪影響がかなり出て困っています。
そのプログラムはシステムに関わっている人みんながあぁ毎日動いているなー程度の認識でした・・・
どうやらすでに退職した人が作ったらしいのですが仕様書などのドキュメント類が全くありません。

とりあえずプログラムの中身を見てくれと頼まれちゃったのですが。。。みんな早々に帰ってし
まい私がこれから会社で夕飯食べながらやる予定です。

VB6で書かれているっぽいのですが、exeファイルを解析したことなんてなくこれから調べながら
やるのですがこんな変な経験を同じようにしたことあるかたいらっしゃいませんか?

参考にさせてください。

補足
    言葉足らずでしたが・・・exeファイルしかない状態です。夕飯もぐもぐしながらドキュメ
    ントを探していますが見つからない状態です。退職者のことは誰も知っている人がいないた
    め自力でなんとかするしかないのですが作り直しの前になんとかリバースエンジニアリング
    でも出来れば・・・


逆アセンブルするとアセンブラのコードができるから、それを頑張って読む。以上。
俺なら受けた瞬間に断るね。もしくは月200万は請求する。

ソースコードがあるのかないのかによって話が違ってくると思います。
ソースコードがあるならば

(略)

ソースコードがない場合、バイナリとの戦いになります。
これは、プロフェッショナルであってもかなり難しい仕事になると言えるでしょう。
もしこれを行わなければいけない場合、素直にあきらめて、一から作り直したほうが早いです。
数年スパンでその仕事に従事できるならまだしも、ちょっと直したいぐらいの仕事として捉えると、ひどい目に合うでしょう。

プログラムの規模にも寄りますが、いずれにせよ、ドキュメントや引継ぎが無い以上、片手間にできる仕事ではありません。
退職された方に連絡をとって、保守についてアドバイスをもらうとか、可能な限り手を尽くしてみるべきでしょう。
もし予算に余裕があれば、専門家に相談されることをおすすめします。

補足に対して:
ソースがないなら、まず無理でしょう。
VB6は、確かexeを吐き出すときに最適化の処理が走ったと思いますので、元のコードを解析することはおろか、動きを追いかけることすら難しいでしょう。
バイナリファイルを読んだことがなかったり、Windowsのexeファイルの構造について深い知識が無いならなおのことです。
逆コンパイラでVBのコードを吐かせてみることも可能ではあると思いますが、とても読むに耐えるシロモノではありません。
(それでも、バイナリを読むよりはマシでしょう)

素直に書き直すか、仕様を固め直して専門家に作り直してもらう事をおすすめします。

okwave にも投げてんのか

作者不詳のプログラムのソースコードを解析する手段はないでしょうか?しか | OKWave
作者不詳のプログラムのソースコードを解析する手段はないでしょうか?しか

作者不詳のプログラムのソースコードを解析する手段はないでしょうか?しか

作者不詳のプログラムのソースコードを解析する手段はないでしょうか?しかもexeファイルしかない状態です。
社内のとあるシステムの一部分のプログラムなのですが突然エラーを起こすようになりました。
これがまたやっかいでユーザーへの悪影響がかなり出て困っています。
そのプログラムはシステムに関わっている人みんながあぁ毎日動いているなー程度の認識でした・・・
どうやらすでに退職した人が作ったらしいのですが仕様書などのドキュメント類が全くありません。
とりあえずプログラムの中身を見てくれと頼まれちゃったのですが。。。みんな早々に帰ってしまい私がこれから会社で夕飯食べながらやる予定です。
VB6で書かれているっぽいのですが、exeファイルを解析したことなんてなくこれから調べながらやるのですがこんな変な経験を同じようにしたことあるかたいらっしゃいませんか?
逆コンパイルなど参考にさせてください。

ANo.3

趣味の領域ならばリバースエンジニアリングというのは
苦労も多いものですが楽しさも入っていますので挑むべきだと思います。

しかし、今回のように会社として使っているものの場合、
解析しようと試みる時間がひたすら無駄です。
解析するのではなく、似たものを一から作る方が楽ですし、結果が伴います。


ANo.2

"decompiler exe"で検索するといろいろ出てきます。

日本語のがあるかは知りませんが。

ANo.1

え?リバースエンジニアリング押し付けられちゃったのですか?

それだと、アセンブラレベルまでしか戻らないからVBとか全く関係無い世界に
なっちゃうし、修正もアセンブラになっちゃいますよ。

ソースコード保管してないかどうか探した方が・・・。

VB6 ってネイティブのバイナリじゃなくて、中間言語でなかったっけ? 質問者はたぶん、「りばーすえんじありんぐ」で楽ができるかもと踏んでるんだろうけど おとなしく0から作ったほうがいいようなあ。こんなの。 といって本来の業務以外でやれといわれるとしおしおのぱーだけどw

■_

melancholic afternoon

http://homepage1.nifty.com/herumi/diary/1006.html#30
6月30日_

  アセンブラ(アセンブリ言語)で書くと本当に、コンパイラーで書いたのよりも速くなるんでしょうか?

まあ一般論で断言しちゃうと話がおかしくなるのでそれはしないとして. 個別論なら, たとえば
こないだやってた暗号系のやつだと多倍長整数が必要なんだけど, CPUのcarryを扱えるコンパイ
ラってあんまし聞いたことないので素直にアセンブリ言語で書いた方が速そう. 後x86やx64用の
Cコンパイラだとsizeof(int) * 2のサイズの乗算, 除算命令を直接使えないことが多いのでそれ
も辛いですね(32bit Cコンパイラで64bit x 64bit→128bit作って, て言われたらどうする?). 
VCだと_umul128(64bit only)や__emuluはあるけど割り算はなさそう. gccには乗算もなさそう
(あったらすまん. 教えてください).

それから私にとってXbyakはC/C++の文法でアセンブリ言語を記述できるのが大きな利点だな. ル
ープのアンロール回数変えながらのベンチマークなんてのも簡単だし. 

ああ、それは確かにそうですね。そっち方面は考えから抜け落ちていました。 sizeof(int) * 2のサイズの乗算 これは自分も経験ありました ○| ̄|_ CPUの命令レベルだと、16bit×16bitで32bitの積が求まっているのににんともかんとも できなかったという。int が 16bit 、long が32bit で、 long hoge = (long)(i * j) でうまいこと拾えたコンパイラーもあったような気がしますが こんなのを期待しちゃいかんですよね。

そういえば昔のWindnows (3.1あたり)には、MulDiv とかいうAPIがあったような記憶が。

■_本日の巡回から

■_ だめだ

もっとスピードがほしい(って中身ぐだぐだでは…)


The History of Python: From List Comprehensions to Generator Expressions

The History of Python

A series of articles on the history of the Python programming language and its community.
Tuesday, June 29, 2010

From List Comprehensions to Generator Expressions
(リスト内包からジェネレーター式へ)


List comprehensions were added in Python 2.0. This feature originated as a set of 
patches by Greg Ewing with contributions by Skip Montanaro and Thomas Wouters. (IIRC 
Tim Peters also strongly endorsed the idea.) Essentially, they are a Pythonic 
interpretation of a well-known notation for sets used by mathematicians. For example, 
it is commonly understood that this:

リスト内包 (List comprehensions) は Pyton 2.0 で追加されました。この機能は Greg Ewing 
によるパッチ群が始まりで、Skip Montanaro とThomas Wouters による contribgutions があり
ました
 (IIRC Tim Peters also strongly endorsed the idea.)。
本質的には、リスト内包とは数学者たちが使っている集合のためのよく知られている記法の
Python 的な解釈 (Pythonic interpretaion) です。たとえば

   {x | x > 10}


refers to the set of all x such that x > 10. In math, this form implies a universal 
set that is understood by the reader (for example, the set of all reals, or the set of 
all integers, depending on the context). In Python, there is no concept of a universal 
set, and in Python 2.0, there were no sets. (Sets are an interesting story, of which 
more in a future blog post.)

これは x > 10 であるすべての x の集合を参照するものとして一般的には理解されています。
数学的には、この形式は reader によって理解される universal set を implies します(たと
えば文脈に応じて、すべての実数の集合であるとかすべての整数の集合であるとか)。Python に
は universal set というconcept は存在せず、また、Python 2.0 には set もありませんでし
た (set にも興味深いストーリーがあるので、いずれ blogで詳しく書きます)。


This and other considerations led to the following notation in Python:


   [f(x) for x in S if P(x)]


This produces a list containing the values of the sequence S selected by the predicate 
P and mapped by the function f. The if-clause is optional, and multiple for-clauses 
may be present, each with their own optional if-clause, to represent nested loops (the 
latter feature is rarely used though, since it typically maps a multi-dimensional 
entity to a one-dimensional list).

これはシーケンス S から述語 (predicate) P により選択され、関数 f により map された値か
らなるリストを生成します。if-clause は省略可能で、ネストしたループを表現するために多重
になっている for-clauses も許されます。そのそれぞれが対応する固有の省略可能な 
if-clause を持てます
(the latter feature is rarely used though, since it typically maps a multi-dimensional 
entity to a one-dimensional list)。


List comprehensions provide an alternative to using the built-in map() and filter() 
functions. map(f, S) is equivalent to [f(x) for x in S] while filter(P, S) is 
equivalent to [x for x in S if P(x)]. One would think that list comprehensions have 
little to recommend themselves over the seemingly more compact map() and filter() 
notations. However, the picture changes if one looks at a more realistic example. 
Suppose we want to add 1 to the elements of a list, producing a new list. The list 
comprehension solution is [x+1 for x in S]. The solution using map() is map(lambda x: 
x+1, S). The part “lambda x: x+1” is Python's notation for an anonymous function 
defined in-line.

リスト内包は、組み込みの map() 関数と filter() 関数を使うことに対してのalternative
(別の選択肢) を提供します。map(f, S) は [f(x) for x in S] と等価であり、filter(P, S) 
は[x for x in S if P(x)] と等価なものです。リスト内包は、よりコンパクトに感じられる 
map() と filter() を使った表記よりもそれほど勧められるものではないと考える人もいるでし
ょう。しかしその見方は、より現実的な例を見たときに変わります。あるリストの全要素に 1を
加えていった新しいリストを生成したいとしましょう。リスト内包を使った solutuon は
[x+1 for x in S] です。map() を使った solution は map(lambda x: x+1, S) です。
“lambda x: x+1” の部分は in-line で無名関数 (anonymous function) を定義するための
Python での表記です


It has been argued that the real problem here is that Python's lambda notation is too 
verbose, and that a more concise notation for anonymous functions would make map() 
more attractive. Personally, I disagree?I find the list comprehension notation much 
easier to read than the functional notation, especially as the complexity of the 
expression to be mapped increases. In addition, the list comprehension executes much 
faster than the solution using map and lambda. This is because calling a lambda 
function creates a new stack frame while the expression in the list comprehension is 
evaluated without creating a new stack frame.

Python の lambda 記法は冗長すぎることがここでの本当の問題であると主張し、そのために 
map() をもっと attractive にするであろう無名関数のためのより一貫した表記についての意見
がありました。わたし個人としては、これには反対です。わたしはリスト内包の記法が関数的記
法よりもずっと読みやすいものであると気がつきました。
especially as the complexity of the expression to be mapped increases.
それに加えて、リスト内包の実行のほうが map と lambda を使った solution よりも格段に高
速です。これは、lambda 関数を呼び出すことで新しいスタックフレームが生成されるのに対し
て、リスト内包の場合は新しいスタックフレームを作ることなしに評価されるからです。


Given the success of list comprehensions, and enabled by the invention of generators 
(of which more in a future episode), Python 2.4 added a similar notation that 
represents a sequence of results without turning it into a concrete list. The new 
feature is called a “generator expression”. For example:

リスト内包の成功とジェネレーター (将来のエピソードで詳しく説明します) の発明により可能
となったので、Python 2.4 においてリスト内包と同様の表記の、リストそのものを返すのでは
なく結果のシーケンスを表すものが追加されました。この新しい機能が“ジェネレーター式”
(generator expression) と呼ばれるものです。例を挙げましょう。

   sum(x**2 for x in range(1, 11))

This calls the built-in function sum() with as its argument a generator expression 
that yields the squares of the numbers from 1 through 10 inclusive. The sum() function 
adds up the values in its argument resulting in an answer of 385. The advantage over 
sum([x**2 for x in range(1, 11)]) should be obvious. The latter creates a list 
containing all the squares, which is then iterated over once before it is thrown away. 
For large collections these savings in memory usage are an important consideration.

これは組込み関数の sum() を、その引数として 1 から 10 までの数値の平方を yields するジ
ェネレーター式を伴って呼び出しています。この sum()関数はその平方の値を加算していってそ
の結果として385を得ます。この書き方の、sum([x**2 for x in range(1, 11)])に対するアドバ
ンテージは明らかです。
The latter creates a list containing all the squares,
which is then iterated over once before it is thrown away. 
For large collections these savings in memory usage are an important consideration.



I should add that the differences between list comprehensions and generator 
expressions are fairly subtle. For example, in Python 2, this is a valid list 
comprehension:

わたしは、リスト内包とジェネレーター式との間の違いが fairly subtle であることを付け加
えておくべきでしょうたとえば Python 2 では次のリスト内包は vaild なものです:

   [x**2 for x in 1, 2, 3]


However this is not a valid generator expression:

しかし次のジェネレーター式は valid ではありません:

   (x**2 for x in 1, 2, 3)


We can fix it by adding parentheses around the "1, 2, 3" part:
わたしたちはこれを修正しました
"1, 2, 3" の部分を囲むカッコを追加することで

   (x**2 for x in (1, 2, 3))


In Python 3, you also have to use these parentheses for the list comprehension:
Python 3 では
リスト内包の場合もこの種のカッコを使わなければなりません:

   [x**2 for x in (1, 2, 3)]


However, in a "regular" or "explicit" for-loop,
you can still omit them:
ただし、"regular" や "explicit" な for ループの場合は、
現在でもこのカッコを省略できます:

   for x in 1, 2, 3: print(x**2)


Why the differences, and why the changes to a more restrictive list comprehension in 
Python 3? The factors affecting the design were backwards compatibility, avoiding 
ambiguity, the desire for equivalence, and evolution of the language. Originally, 
Python (before it even had a version :-) only had the explicit for-loop. There is no 
ambiguity here for the part that comes after 'in': it is always followed by a colon. 
Therefore, I figured that if you wanted to loop over a bunch of known values, you 
shouldn't be bothered with having to put parentheses around them. This also reminded 
me of Algol-60, where you can write:

違うのはなぜか? また、Python 3におけるリスト内包をより厳密なものに変更したのはなぜか?
設計に影響を与えた要素は、後方互換性、曖昧性の除去、等価性の要求、言語の進化です。元々、
Python には explicit な for ループしかありませんでした (バージョン番号がつく以前の話
です :-)。 そこにはあいまいさはなく、'in' の後ろには常にコロンが来ていました。
したがってわたしは、あなたがもし既知の値の集まり (bunch of known values) に対してルー
プを行いたいのなら、それらの周りにカッコをつけることを厭うべきではないという指摘をしま
す。このことは以下の例のように書ける Algol-60 をわたしに思い起こさせます


   for i := 1, 2, 3 do Statement


except that in Algol-60 you can also replace each expression with
step-until clause, like this:


   for i := 1 step 1 until 10, 12 step 2 until 50, 55 step 5 until 100 do Statement


(In retrospect it would have been cool if Python for-loops had the
ability to iterate over multiple sequences as well. Alas...)

When we added list comprehensions in Python 2.0, the same reasoning
applied: the sequence expression could only be followed by a close
bracket ']' or by a 'for' or 'if' keyword. And it was good.

わたしたちは Python 2.0 にリスト内包を追加したときに同じ理由、
シーケンス式はクローズブラケット ']' 、もしくは
'for' キーワードか 'if' キーワードが後続する場合のみ可能である
を適用しました:


But when we added generator expressions in Python 2.4, we ran into a problem with 
ambiguity: the parentheses around a generator expression are not technically part of 
the generator expression syntax. For example, in this example:

しかし Python 2.4 でジェネレーター式を追加したとき、曖昧性の問題につきあたりました:
ジェネレーター式を囲むカッコは技術的にはジェネレーター式構文 (generator expression 
syntax) の一部ではありません。たとえば次のような例で:


   sum(x**2 for x in range(10))


the outer parentheses are part of the call to sum(), and a"bare" generator 
expression occurs as the first argument. So in theory there would be two 
interpretations for something like this:

外側のカッコは sum() の呼び出しの一部であり、"bare" なジェネレーター式は
sum() の第一引数に現れています。ですから理論的には以下のようなものは二通りの解釈ができ
るのです:

   sum(x**2 for x in a, b)


This could either be intended as:

   sum(x**2 for x in (a, b))


or as:

   sum((x**2 for x in a), b)


After a lot of hemming and hawing (IIRC) we decided not to guess in this case, and the 
generator comprehension was required to have a single expression (evaluating to an 
iterable, of course) after its 'in' keyword. But at the time we didn't want to break 
existing code using the (already hugely popular) list comprehensions.

a lot of hemming and hawing (IIRC) のあとで、わたしたちは not to guess in this case, 
ジェネレーター内包は、自身の 'in' キーワードのあとに単一の式 (single expression。これ
は当然 evaluating to an iterableなものです) を要求するものと決定しました。しかしその時
点では、わたしたちはリスト内包を使っている既存のコード(すでに hugely popular でした)を
壊したくはありませんでした。


Then when we were designing Python 3, we decided that we wanted the
list comprehension:

その後わたしたちが Python 3 を設計していたときに、



   [f(x) for x in S if P(x)]


to be fully equivalent to the following expansion using the built-in list() function 
applied to a generator expression:

上記のようなリスト内包が、組込みの list() 関数をジェネレーター式を使った式と完全に等価
なもの (fully equivalent) にしようとしたのです:

   list(f(x) for x in S if P(x))


Thus we decided to use the slightly more restrictive syntax of generator expressions 
for list comprehensions as well.

そこでわたしたちは、ジェネレーター式のより制限された構文をリスト内包にも同様に使うよう
に決めました。

We also made another change in Python 3, to improve equivalence between list 
comprehensions and generator expressions. In Python 2, the list comprehension 
"leaks" the loop control variable into the surrounding scope:

わたしたちはまた、リスト内包とジェネレーター式の間の等価性を向上させる (improve) ため
のもう一つの変更を Python3 で行いましたPython 2ではリスト内包はそのループ制御変数がそ
れを囲むスコープに“漏れて”(leak)いたのです:


   x = 'before'
   a = [x for x in 1, 2, 3]
   print x # this prints '3', not 'before'


This was an artifact of the original implementation of list comprehensions; it was one 
of Python's "dirty little secrets" for years. It started out as an 
intentional compromise to make list comprehensions blindingly fast, and while it was 
not a common pitfall for beginners, it definitely stung people occasionally. For 
generator expressions we could not do this. Generator expressions are implemented 
using generators, whose execution requires a separate execution frame. Thus, generator 
expressions (especially if they iterate over a short sequence) were less efficient 
than list comprehensions.


これはリスト内包のオリジナル実装の artifact (人工物?) で、Python が長年抱えていた 
"dirty little secrets" のひとつでした。これはリスト内包を blindigly fast に
するために意図的に compromise されたものとして始まりました。そして、これがビギナーにと
っての common pitfall (はまりがちな落とし穴)でない間は本の一部の人たちだけがこれに異議
を申し立てていたのです。わたしたちはジェネレーター式に対してはこの実装を使えませんでし
た。ジェネレーター式はジェネレーターを使って実装されていて、実行時に分割された実行フレ
ームを要求します。したがって、特に短いシーケンスに対してイテレートする場合にはジェネレ
ータ式はリスト内包よりも効率の点で劣っていました。



However, in Python 3, we decided to fix the "dirty little secret" of list 
comprehensions by using the same implementation strategy as for generator expressions. 
Thus, in Python 3, the above example (after modification to use print(x) :-) will 
print 'before', proving that the 'x' in the list comprehension temporarily shadows but 
does not override the 'x' in the surrounding scope.

しかし Python 3 でわたしたちはこのリスト内包の "dirty little secret"を、ジェ
ネレーター式のそれと同様の実装を行うことによって修正することにしました。したがって 
Python 3 では、先の例は 'before' を出力します (print(x)に修正したあとで、ですが :-)。
リスト内包の中にある 'x' は一時的に隠され (shadows) ますが、それはリスト内包を囲むスコ
ープにある 'x' をオーバーライドしません。



And before you start worrying about list comprehensions becoming slow in Python 3: 
thanks to the enormous implementation effort that went into Python 3 to speed things 
up in general, both list comprehensions and generator expressions in Python 3 are 
actually faster than they were in Python 2! (And there is no longer a speed difference 
between the two.)

Python 3 でリスト内包が遅くなったのではないかとあなたが心配し始める前に: 一般的にスピ
ードについてPython 3 で払われた enormous implementation effort のおかげで、Python 3 に
おけるリスト内包とジェネレーター式の両方とも実際の速度は Python 2 のそれよりも高速にな
っているのです! (そしてこの両者の間の速度差はもはやありません)


UPDATE: Of course, I forgot to mention that Python 3 also supports set comprehensions 
and dictionary comprehensions. These are straightforward extensions of the list 
comprehension idea. Posted by Guido van Rossum at 8:39 AM

言うまでもないことですが、Python 3 では set 内包や dictionary 内包もサポートしていると
いうことに言及するのを忘れていました。これらは、リスト内包の考え方の straightforward
な extensions です。

2010年06月29日

■_

・誤字
というか誤用か。 ちょっと偉い人がその手の間違いをしているとなんだかなー。微妙な気分に。

・まんがライフMONO
佐藤両々の新連載がなんかツボにはいったっぽい(笑)

■_

条件がいろいろあり得るだろうというのは容易に想像がつくので、 まあそういう場合もあるんじゃない程度の意見です


Island Life - アセンブラをぶっとばせ
アセンブラをぶっとばせ

http://twitter.com/vitroid/status/17262472219

    開発者の生産性を上げるために新しい言語が創られる。速けりゃいいならアセンブラで書けばいい。
    RT @osiire: これは私の周りの狭い世界では逆。 > "むしろ大部分のコードは今以上の
    性能を求められてると言えるんじゃなかろうか。" http://bit.ly/bDlkJS 

「速さが欲しいならアセンブリで書けばいいじゃない」っていうのは、 ひとつ重要な条件を見
落としてるよ。仕事で開発してるなら、 開発期間っていうのはコストだから、上限がある。 従
って求められているのは、「所定の時間内で速いコードを書く」っていうこと。

最適化は時間内にどれだけ色々なアプローチで「実装→計測」のサイクルを 回せるかっていう
のが決め手だが、アセンブリや低レベル言語で書いてる場合、 アプローチを切り替えるコスト
がばか高い。別のアルゴリズムを試したい 場合や、コードに影響を与えるパラメータを変えて
実験したい場合 (簡単な例では、ループのunrollingをいくつ単位でやるか、とか) に手間がか
かるからね。

(以下略)

アセンブラ(アセンブリ言語)で書くと本当に、コンパイラーで書いたのよりも速くなるんでしょうか? 広い意味合いで捉えれば、上の引用部分にもある「所定の時間内で速いコードを書く」という 部分に関係してくるのでしょうがそれはまあ脇に避けて。

今はCコンパイラーでもかなり賢い最適化してくれるし、そういったコードよりも性能の優れた コードを手書きで書くというのはかなり大変だし、 誰にでもできることではないのではないでしょうか (とまで書くと話を広げすぎ?)?

ここ数日、いつだそうかと思っていたネタをここで! と思ったけどちょっと方向が違うっぽいなあ ○| ̄|_

lbrandy.com » Blog Archive » You can't beat a good compiler… right?

by Louis Brandy

You can't beat a good compiler… right?
(キミは優れたコンパイラーを打ちのめすことはできない…本当に?)


Right! Sort of.

It is extremely well worn conventional wisdom that for your “average” programmer, 
it's pretty much impossible to beat a good optimizing compiler at writing fast code. 
For those who skip the “understanding” part, and jump straight into the “application”
part, this rule of thumb tends to be grossly misunderstood, and misused. For these 
people, compilers are so smart, and so good, that micro-optimization is basically 
impossible (uh, no), or too hard (no), or even that they make assembly knowledge 
unnecessary or obsolete (not even close). This tends to lead to a mentality that 
optimization can be left to the compiler and often results in people warning others to 
not bother with micro-optimizations at all.

Optimization, today, is largely about writing some naive code, looking at the assembly 
output, figuring out what you want to improve on, and then getting (or, often, 
tricking) the compiler into doing what you want. After several iterations of this, you 
end up with the code you want, and you gain all the benefits of having a compiler in 
the loop (portability, future-proofing, and so on). This process, though, obviously 
involves a great deal of low-level knowledge: assembly, cpu architecture, 
micro-optimizations that are likely to work, etc.

As an aside, I have a question: how exactly does one go about learning how to go 
beyond standard C into hardcore optimization? For me, it's been a long road of trial 
& error, and random discovery. It seems to me that there is probably good 
resources out there for getting started on optimizing code (let's say in gcc). Know 
any?

(以下略)

■_てんぷれ


C++相談室 part82 
388 デフォルトの名無しさん [sage] 2010/06/27(日) 09:01:43 ID: Be:
    テンプレートが全く理解できないんだけど、お前らはプログラミングで使ってるの? 

389 デフォルトの名無しさん [sage] 2010/06/27(日) 09:10:01 ID: Be:
    普通に使うよ
    最初はとまどったけど参考書も結構でてるし、boostっていう無料で質量最高のサンプルもあるし勉強はしやすい 

390 デフォルトの名無しさん [sage] 2010/06/27(日) 09:25:00 ID: Be:
    テンプレートのないC++はintしかないCみたいなもん 

391 388 [sage] 2010/06/27(日) 09:25:47 ID: Be:
    テンプレートって黒魔術じゃないんですか? 

392 デフォルトの名無しさん [sage] 2010/06/27(日) 09:42:42 ID: Be:
    黒魔術上等、テンプレートは必須科目だね。 

393 デフォルトの名無しさん [sage] 2010/06/27(日) 10:37:54 ID: Be:
    template禁止なC++なんて魅力半減ですわ。

394 デフォルトの名無しさん [sage] 2010/06/27(日) 10:58:21 ID: Be:
    >>388
    その理解できないというテンプレートって何?
    spiritだったら許す 


395 デフォルトの名無しさん [sage] 2010/06/27(日) 13:05:41  ID: Be:
    テンプレートライブラリはよく使用するけど
    自分ではあまり定義したりしないかな 

396 デフォルトの名無しさん [sage] 2010/06/27(日) 13:22:01 ID: Be:
    traitsの概念を理解するのが難しかったな 

397 デフォルトの名無しさん [sage] 2010/06/27(日) 13:24:19 ID: Be:
    もうBoostは当たり前なのか。 

398 デフォルトの名無しさん [sage] 2010/06/27(日) 13:43:15 ID: Be:
    個人的には当たり前だけど、仕事ではboostは禁止されている
    STLの使用も最初は禁止されていて、俺が熱弁を振るってようやく
    使用許可が出た位だ 

399 デフォルトの名無しさん [sage] 2010/06/27(日) 13:44:33 ID: Be:
    つーかshared_ptrがtr1に入ってよかったわ
    これがないとスマポをコンテナに入れられない
    カタワになっちまう 

401 デフォルトの名無しさん [sage] 2010/06/27(日) 14:28:32 ID: Be:
    新規格にはテンプラテク用途に使えそうなものも多いし黒魔術どころか順標準といっもよくなってきた感じはする 

402 デフォルトの名無しさん [sage] 2010/06/27(日) 17:07:30 ID: Be:
    >>398
    なんで禁止されそうになったの? 

403 デフォルトの名無しさん [sage] 2010/06/27(日) 17:29:10 ID: Be:
    「禁止されていた」と書いてあるが 

404 デフォルトの名無しさん [sage] 2010/06/27(日) 17:54:58 ID: Be:
    google先生もSTL禁止だな 

405 デフォルトの名無しさん [sage] 2010/06/27(日) 17:56:54 ID: Be:
    万一 STL にバグがあっても特定できないし。 

406 デフォルトの名無しさん [sage] 2010/06/27(日) 18:12:11 ID: Be:
    万一 コンパイラにバグがあっても特定できないし。 

407 デフォルトの名無しさん [sage] 2010/06/27(日) 18:16:18 ID: Be:
    万が一 OSにバグがあっても特定できないし。 

408 デフォルトの名無しさん [sage] 2010/06/27(日) 18:37:45 ID: Be:
    万が一 HWにバグがあっても特定できないし。 

409 デフォルトの名無しさん [sage] 2010/06/27(日) 18:44:21 ID: Be:
    万が一地球にバグがあっても特定できないし。 

410 デフォルトの名無しさん [sage] 2010/06/27(日) 18:45:17 ID: Be:
    HWのバグは経験したことないけどOSのバグとかライブラリのバグは特定できるでしょ 

411 デフォルトの名無しさん [sage] 2010/06/27(日) 19:35:01 ID: Be:
    散々悩んだ挙句にな 

412 デフォルトの名無しさん [sage] 2010/06/27(日) 19:41:49 ID: Be:
    ジョークにマジレスする男の人って… 

conecpt さんの話題が出てこなかったw

■_本日の巡回から

2010年06月28日

■_

どーして、書店やコンビニで雑誌を立ち読みしている連中は態度がでかいのか。 数人並んで立ち読みしているからどの雑誌がどこにあるのかも良くわからないし、 確認するために押しのけて入っていくと露骨にいやな顔をする (まあ、立ち読みに参加するとでも思ったのだろう)。

■_ Perl 6

Journal of chromatic (983)

Perl 6 Design Minutes for 16 June 2010

[ #40419 ]

The Perl 6 design team met by phone on 16 June 2010. Larry, Allison, Patrick, Will, and chromatic attended.

Larry:

    * documented TOP (again), and explained how parsing is initiated and how it actually works
    * series operator (...) now picks a monotonic function when using single characters as endpoints
    * STD can now catch duplicates involving protos as well as onlys
    * STD no longer advises removal of parens on spaceless sub() declaration
    * mostly advised sorear and pmichaud
    * Stefan is finishing the boostrap of the STD parser
    * also working on adding a parallel NFA and DFA engine
    * no, he doesn't want to generate all the states in advance
    * it works faster lazily

(略)

Patrick:

    * Rakudo developers decided not to make extra special effort to make a June release of Rakudo Star
    * the calendar works against us
    * the new date for the release is July 29
    * we're I comfortable with hitting that target
    * we won't be happy with the results of moving heaven and earth to release in June
    * there are lots of advantages
    * one disadvantage is not having Rakudo Star at YAPC::NA
    * one big advantage is using the supported Parrot 2.6 release as the basis
    * I'll write a post outlining the plan in the next couple of days
    * otherwise working on lists and interators in Perl 6 and Rakudo
    * after deciding to make iterators immutable, Larry and I realized that solves many problems
    * everything works out as plain as day after that
    * very happy with that design
    * the incorrect assumptions of the old model were pervasive
    * replacing the old pieces is taking a while, which is no surprise
    * this approach feels right though
    * the new branch does things no previous version could do
    * slices work much better, for example
    * metaoperators work properly
    * map is lazy
    * slurpy arguments in lists are lazy by default
    * no weird binding or action at a distance problems
    * plenty of changes to Associative and Positional roles
    * those are now super clean and may be lazy
    * more features work
    * ~30 failing tests (not test files, just tests) now, ~500 last night
    * most of the current failures are minor
    * will try to merge the branch before the release
    * replacing lots of ugly code with fewer lines of elegant code
    * Jonathan and others have worked on lots of other pieces
    * adding plenty of new features
    * looking forward to tomorrow's release

c:

    * editing the Rakudo book
    * moving the Rakudo release date may let us have a printed book available about the same time
    * depends on how much there is left to write

series operator (...) now picks a monotonic function の monotonic ってなんじゃらほい。 あと、rakudo star でいろいろ話題が出てますね。 んで、本も編集中と。

■_ Go

オライリーのサイトにあった記事なので控えめに(笑)

Does the world need another programming language? - O'Reilly Radar
http://radar.oreilly.com/2010/06/does-the-world-need-yet-anothe.html

Does the world need another programming language?
世界はもう一つのプログラミング言語を必要としているのだろうか?

Rob Pike on how and why Google's new Go language was developed.

by James Turner

(略)

*What's it like to program in Go?

    RP: Go has the feel of a dynamic language like Python or Ruby or JavaScript, but
    it has the performance and safety of a language like Java or C or C++. So you get
    the lightweight feel of a modern scripting dynamic language but the robustness and
    performance of a more old-fashioned language.


(略)

*Does the world need another programming language?


    RP: It's an interesting time for languages because there are many new languages 
    coming about. There was a burst of language development in the late '60s and early 
    '70s and then things died down. That's not to say there weren't any new languages 
    coming along, but language design didn't seem to be a very profitable enterprise. But 
    then in the last five to ten years, there's been a renaissance. One of the reasons for 
    that phenomenon, which is what I'm going to talk about at OSCON, is that the languages 
    in common use today don't seem to be answering the questions that people want answered. 
    There are niches for new languages in areas that are not well-served by Java, C, C++, 
    JavaScript, or even Python.

(略)

Rob Pike will discuss Go's development at the OSCON conference (July 19-23 in Portland, Ore.)
OSCON will also be the site of the first Emerging Languages Camp.

burst of language development とな。

■_ 力尽きた

あとで追加します ○| ̄|_

The History of Python: The Inside Story on New-Style Classes

The History of Python

A series of articles on the history of the Python programming language and its community.

Monday, June 21, 2010

The Inside Story on New-Style Classes
(新形式クラスのインサイドストーリー)


[Warning, this post is long and gets very technical.]

On the surface, new-style classes appear very similar to the original class 
implementation. However, new-style classes also introduced a number of new concepts:

表面的には新形式クラスは旧形式のクラスの実装 (original class implementation) と非常に
似通って見えます。しかし、新形式クラスは新しいコンセプトもいくつか取り込んでいるのです:


    * low-level constructors named __new__()
      (低レベルコンストラクターと__new__())

    * descriptors, a generalized way to customize attribute access

    * static methods and class methods
      (スタティックメソッドとクラスメソッド)

    * properties (computed attributes)
      (プロパティ)

    * decorators (introduced in Python 2.4)
      (デコレーター)

    * slots
      (スロット)

    * a new Method Resolution Order (MRO)
      (新しいメソッド探索順序)


In the next few sections, I will try to shine some light on these concepts.

続くいくつかのセクションで、これらのコンセプトに対して光を当てて明らかにしようと考えて
います。


*Low-level constructors and __new__()
(低レベルコンストラクターと__new__())

Traditionally, classes defined an __init__() method which defined how new instances 
are initialized after their creation. However, in some cases, the author of a class 
may want to customize how instances are created―for example, if an object was being 
restored from a persistent database. Old-style classes never really provided a hook 
for customizing the creation of objects although there were library modules allowed 
certain kinds of objects to be created in non-standard ways (e.g., the "new" 
module).

伝統的にクラスは、新しいインスタンスが生成された後にそれがどのように初期化されるのかを
定義する__init__() メソッドを定義します。しかしながら一部のケースにおいて、クラスの 
author がたとえばあるオブジェクトが永続的データベース (persistent database) からリス
トアされた場合に、インスタンスをどのように生成するかをカスタマイズすることを希望するか
もしれません。標準でない方法で生成するようなオブジェクトを許すようなライブラリモジュー
ル(たとえば“new”モジュール) が存在していたにも関わらず、旧形式のクラスではオブジェク
トの生成をカスタマイズするためのフックを決して提供しませんでした。



New-style classes introduced a new class method __new__() that lets the class author 
customize how new class instances are created. By overriding __new__() a class author 
can implement patterns like the Singleton Pattern, return a previously created 
instance (e.g., from a free list), or to return an instance of a different class (e.g., 
a subclass). However, the use of __new__ has other important applications. For example, 
in the pickle module, __new__ is used to create instances when unserializing objects. 
In this case, instances are created, but the __init__ method is not invoked.

新形式のクラスでは、クラスの author に新しいクラスのインスタンスをどのように生成するか
をカスタマイズさせる新しいクラスメソッド __new__() を導入しました。__new__() をオーバ
ーライドすることにより、author は以前に生成していたインスタンスを (たとえばフリーリス
トから) 返したりあるいは (サブクラスのような) 異なるクラスのインスタンスを返すといった
シングルトンパターン (Singleton Pattern) のようなパターンを実装できます。この他にも、
__new__ の使用には重要な application (応用例) があります。たとえば pickle モジュールで
は、__new__ はオブジェクトがシリアライズされていない (unserializing) ときにインスタン
スを生成するのに使われます。この場合インスタンスは生成されますが、__init__ メソッドは
起動されません。


Another use of __new__ is to help with the subclassing of immutable types. By the 
nature of their immutability, these kinds of objects can not be initialized through a 
standard __init__() method. Instead, any kind of special initialization must be 
performed as the object is created; for instance, if the class wanted to modify the 
value being stored in the immutable object, the __new__ method can do this by passing 
the modified value to the base class __new__ method.

もうひとつの __new__ の使い方は immutable types (変更不能な型) のサブクラスを手助けす
るものです。その immutability という性質によって、この種のオブジェクトは標準の 
__init__() メソッドを通じた初期化ができません。その代わりとして、あらゆる種類の特殊な
初期化はオブジェクトの生成として行われなければなりません。たとえばクラスが immutable 
なオブジェクトに格納されている値を変更しようとしたならば、そのオブジェクトの __new__ 
メソッドは変更された値を自分のベースクラスの __new__ メソッドに渡すことによってこれを
達成するかもしれません。


*Descriptors (ディスクリプター)

Descriptors are a generalization of the concept of bound methods, which was central to 
the implementation of classic classes. In classic classes, when an instance attribute 
is not found in the instance dictionary, the search continues with the class 
dictionary, then the dictionaries of its base classes, and so on recursively. When the 
attribute is found in a class dictionary (as opposed to in the instance dictionary), 
the interpreter checks if the object found is a Python function object. If so, the 
returned value is not the object found, but a wrapper object that acts as a currying 
function. When the wrapper is called, it calls the original function object after 
inserting the instance in front of the argument list.

ディスクリプターは bound methods (束縛メソッド?) のコンセプトの一般化で、classic クラ
スの実装の中核となっていたものです。classic クラスではあるインスタンスの属性がそのイン
スタンスの辞書から見つからなければ検索をそのクラスの辞書で継続し、さらにそのベースクラ
スの辞書、さらにそのベースクラスと再帰的に続けます。attribute が (インスタンス辞書では
なく) クラス辞書で見つかった場合、インタープリターは見つかったそのオブジェクトが 
Python の関数オブジェクトであるかどうか検査します。もし関数オブジェクトであれば、返さ
れる値は見つかったオブジェクトではなく、カリー化する関数 (currying fuction) として振
舞うラッパーオブジェクトになります。そのラッパーは呼び出されたときに、引数リストの先頭
にインスタンスを挿入した上でオリジナルの関数オブジェクトを呼び出します



For example, consider an instance x of a class C. Now, suppose that one makes a method 
call x.f(0). This operation looks up the attribute named "f" on x and calls 
it with an argument of 0. If "f" corresponds to a method defined in the 
class, the attribute request returns a wrapper function that behaves approximately 
like the function in this Python pseudocode:

たとえば あるクラス C のインスタンス x を考えてみましょう。ここで、ある人が x.f(0) と
いうメソッド呼び出しを行ったとします。このオペレーションは x 上に属する “f” という名
前の属性を検索して、それから0 という引数つきで呼び出します。もし“f”がそのクラスで定
義されたメソッドに一致していたのならその attribute は概ね以下の疑似 Python コードのよ
うに振る舞うラッパー関数を返すことをリクエストします。

def bound_f(arg):
         return f(x, arg)


When the wrapper is called with an argument of 0, it calls "f" with two 
arguments: x and 0. This is the fundamental mechanism by which methods in classes 
obtain their "self" argument.

このラッパーが引数 0 を与えられて呼び出されたとき、ラッパーは二つの引数 x と 0 を与え
て “f” を呼び出します。これが、クラス中のメソッドが“self”引数を獲得した (obtain) 
ことによる fundamental (基礎をなす、重要な)な機構です


Another way to access the function object f (without wrapping it) is to ask the class 
C for an attribute named “f”. This kind of search does not return a wrapper but 
simply returns the function f. In other words, x.f(0) is equivalent to C.f(x, 0). This 
is a pretty fundamental equivalence in Python.

もうひとつの、(ラッピングされていない) 関数オブジェクト f にアクセスする方法がクラス C 
に “f”という名の属性に対する問い合わせをするというものです。この種の検索はラッパーを
返さず、ただ単に関数 f を返します。言い換えると、x.f(0) は C.f(x, 0) と等価です。これ
は Python における pretty fundamental equivalence (非常に根本的な等値?) です。


For classic classes, if the attribute search finds any other kind of object, no 
wrapper is created and the value found in the class dictionary is returned unchanged. 
This makes it possible to use class attributes as “default” values for instance 
variables. For example, in the above example, if class C has an attribute named “a” 
whose value is 1, and there is no key “a” in x’s instance dictionary, then x.a 
equals 1. Assignment to x.a will create an key “a” in x’s instance dictionary whose 
value will shadow the class attribute (by virtue of the attribute search order). 
Deleting x.a will reveal the shadowed value (1) again.

classic クラスに対する attribute の検索で、何か別の種類のオブジェクトが見つかったのな
らラッパーは生成されず、クラス辞書で見つかった値は変更されずに返されます。これはクラス
のattibutes をインスタンス変数の“デフォルト”の値として使うことを可能にします。たとえ
ば先の例で、クラス C がその保持する値が 1 である “a”という名前の attribute を持って
いるのであれば、x のインスタンス辞書には“a”というキーは存在せずに x.a は 1 に等しく
なります。x.a に対する代入は “a”というキーをxのインスタンス辞書に作り、そしてその値
はクラスの attribute を隠し (shadow) ます。x.a を削除すると隠されていた値(1) が再び姿
を現します。

Unfortunately, some Python developers were discovering the limitation of this scheme. 
One limitation was that it was prevented the creation of “hybrid” classes that had 
some methods implemented in Python and others in C, because only Python functions were 
being wrapped in such a way as to provide the method with access to the instance, and 
this behavior was hard-coded in the language. There was also no obvious way to define 
different kinds of methods such as a static member functions familiar to C++ and Java 
programmers.

残念なことに、一部の Python 開発者たちはこの手法の限界を見つけてしまいました。制限の一
つはこの手法が一部のメソッドを Python で実装し、その他の部分をCで実装している“ハイブ
リッド” なクラスの生成を阻害してしまうというもので、これは Python のみで構成された関
数はインスタンスに対するアクセスを伴ったメソッドを提供するような方法でラップされるため
であり、またその振る舞いはその言語にハードコード(hard-coded) されているからです。また、
C++ プログラマーや Java プログラマーに馴染みの深いstatic メンバー関数のようなメソッド
を定義する obviousな方法もありません。


To address this issue, Python 2.2 introduced a straightforward generalization of the 
above wrapping behavior. Instead of hard-coding the behavior that Python function 
objects are wrapped and other objects aren’t, the wrapping is now left up to the 
object found by the attribute search (the function f in the above example). If the 
object found by an attribute search happens to have a special method named __get__, it 
is considered to be a "descriptor" object. The__get__ method is then called 
and whatever is returned is used to produce the result of the attribute search. If the 
object has no __get__ method, it is returned unchanged. To obtain the original 
behavior (wrapping function objects) without special-casing function objects in the 
instance attribute lookup code, function objects now have a __get__method that returns 
a wrapper as before. However, users are free to define other classes with methods 
named __get__, and their instances, when found in a class dictionary during an 
instance attribute lookup, can also wrap themselves in any way they like.

この問題に対処するために、Python 2.2 で straightforward な generalization of the above 
wrapping behavior を導入しました。Python による関数オブジェクトがラップされ、それ以外
のオブジェクトがラップされないという振る舞いをハードコーディングするのではなく、
attribute の検索によって見つかったオブジェクトに対してラッピングするようになりました
(関数 f は先の例のものです)。attribute 検索によってオブジェクトが見つかったのなら、
__get__という名前を持った特殊メソッドを得て、これを“ディスクリプター”オブジェクトで
あるとみなします。そのあと __get__ メソッドが呼び出され、attribute 検索の結果を生成す
るために使われたものがなんであれ返されます。オブジェクトが __get__ メソッドを持ってい
なかった場合には、値を変更せずに戻ります。インスタンスの attribute 検索コードで 
special-casing function objects なしに元々の振る舞い (ラップした関数オブジェクト) を得
るために、関数オブジェクトは以前の ラッパーを返す __get__ メソッドを持っています。ただ
し、ユーザーは自由に __get__ という名前のメソッドを持った別のクラスを定義できますし、
インスタンスもつくれますし、インスタンスの attribute を lookup しているときにクラス辞
書で見つかったのならば、それ自身もまた好きな方法でラップすることが可能です。

#ちょーびみょー

In addition to generalizing the concept of attribute lookup, it also made sense to 
extend this idea for the operations of setting or deleting an attribute. Thus, a 
similar scheme is used for assignment operations such as x.a = 1 or del x.a. In these 
cases, if the attribute "a" is found in the instance's class dictionary (not 
in the instance dictionary), the object stored in the class dictionary is checked to 
see if it has a __set__ and __delete__ special method respectively. (Remember that 
__del__ has a completely different meaning already.) Thus, by redefining these methods, 
a descriptor object can have complete control over what it means to get, set, and 
delete an attribute. However, it's important emphasize that this customization only 
applies when a descriptor instance appears in a class dictionary―not the instance 
dictionary of an object.

attribite の lookup の一般化 (generalozomg) に加えてattribite のセットや削除の操作に対
するこのアイデアを拡張することにも意味があります。そこで、同様の手法は x.a = 1 のよう
な代入操作や del x.a のような操作に対しても使われています。その場合、(インスタンスのイ
ンスタンス辞書ではなく) インスタンスのクラス辞書でattribute “a”が見つかったならば、
クラス辞書に格納されているオブジェクトはそれが期待される特殊メソッドの __set__ や 
__delete_ を持っているか検査されます
(Remember that __del__ has a completely different meaning already.)。
したがってこれらのメソッドを再定義することで、ディスクリプターオブジェクトはattribute 
を get、set、delete するような完全な制御を持つことが可能になります。ただしこのカスタマ
イズは、ディスクリプターのインスタンスがオブジェクトのインスタンス辞書ではなくクラス辞
書中に現れたときにだけ適用されることを強調しておくのは重要です。



*staticmethod, classmethod, and property (静的メソッド、クラスメソッド、プロパティ)


Python 2.2 added three predefined classes: classmethod, staticmethod, and property, 
that utilized the new descriptor machinery. classmethod and staticmethod were simply 
wrappers for function objects, implementing different __get__methods to return 
different kinds of wrappers for calling the underlying function. For instance, the 
staticmethod wrapper calls the function without modifying the argument list at all. 
The classmethod wrapper calls the function with the instance's class object set as the 
first argument instead of the instance itself. Both can be called via an instance or 
via the class and the arguments will be the same.

Python 2.2 では classmethod, staticmethod, property の三つの定義済みクラスを追加しまし
た。これらは新しいディスクリプターを機械的 (machinery) に一般化 (utilized) したもので
す。classmethod と staticmethod は関数オブジェクトに対する単なるラッパーで、その下にあ
る (underlying) 関数を呼び出すためのラッパー以外のものを返すための異なる __get__ メソ
ッドを実装していました。たとえば staticmethod ラッパーは、引数リストを変更することなく 
(ラップしている) 関数を呼び出します。classmethod ラッパーは、第一引数にインスタンス自
身の代わりにインスタンスのクラスオブジェクトをセットして関数を呼び出します。インスタン
スを通じての呼び出しとクラスを通じての呼び出しの両方が可能で、その引数は同じものになり
ます。

The property class is a wrapper that turned a pair of methods for getting and setting 
a value into an"attribute." For example, if you have a class like this,

property クラスは、メソッドのペアをある  "attribute." に対して値をセットした
りゲットしたりするものに変えるラッパーです。たとえば次のようなクラスがあったとすると

    class C(object):
        def set_x(self, value):
            self.__x = value
        def get_x(self):
            return self.__x

a property wrapper could be used to make an attribute "x" that when accessed, 
would implicitly call the get_x and set_x methods.

プロパティラッパーは、attribute “x” をアクセスされたときに暗黙のうち (implicitly) 
に get_x や set_x メソッドを呼び出すようにするために使うことが可能でした。

When first introduced, there was no special syntax for using the classmethod, 
staticmethod, and property descriptors. At the time, it was deemed too controversial 
to simultaneously introduce a major new feature along with new syntax (which always 
leads to a heated debate). Thus, to use these features, you would define your class 
and methods normally, but add extra statements that would "wrap" the methods. 
For example:

クラスメソッドやスタティックメソッド、プロパティディスクリプターが最初に導入されたとき
には、それらのための特別の構文はありませんでした。その時点では、major な新しい機能をそ
れと関係する新しい構文と共にいっせいに (simultaneously) 導入することにはtoo 
controversial (議論の余地がありすぎる) と考えられていました(which always leads to a 
heated debate)。このためこれらの機能を使うためには、クラスとメソッドを通常通り定義する
のですが、メソッドを“ラップ”(wrap) する extra statements を追加します。
例を挙げましょう:


    class C:
        def foo(cls, arg):
            ...
        foo = classmethod(foo)
        def bar(arg):
            ...
        bar = staticmethod(bar)

For properties, a similar scheme was used:

プロパティに対して、同様のスキームが使われます:

    class C:
     def set_x(self, value):
         self.__x = value
     def get_x(self):
         return self.__x
     x = property(get_x, set_x)


*Decorators (デコレーター)


A downside of this approach is that the reader of a class had to read all the way till 
the end of a method declaration before finding out whether it was a class or static 
method (or some user-defined variation). In Python 2.4, new syntax was finally 
introduced, allowing one to write the following instead:

このアプローチの downside (弱点、否定的側面) は、あるクラスの読み手 (reader) がそれが 
class メソッドなのか static メソッド (あるいはなんらかのユーザー定義のバリエーション)
なのかか判断できるまではメソッドの宣言の終わりにいたるまで全部を読まなければならないこ
とです。Python 2.4 で新しい構文がようやく導入され、以下のような書き方が許されるように
なりました:


    class C:
      @classmethod
      def foo(cls, arg):
         ...
      @staticmethod
      def bar(arg):
         ...

The construct @expression, on a line by itself before a function declaration, is 
called a decorator. (Not to be confused with descriptor, which refers to a wrapper 
implementing __get__; see above.) The particular choice of decorator syntax (derived 
from Java's annotations) was debated endlessly before it was decided by “BDFL 
pronouncement”. (David Beazley wrote a piece about the history of the term BDFL that 
I'll publish separately.)

関数宣言の前の行に置かれた @exprresion という construct はデコレーターと呼ばれるもので
す。(ラッパーを実装する __get__ を参照しているディスクリプターと混同しないでください。
see above.)。(Java のアノテーションから派生した) デコレーターの構文の選択については“
BDFL pronouncement”によって決定されるまで。終わりなき論争 (debated emdlesly) を引き起
こしました。
(David Beazley wrote a piece about the history of the term BDFL that I'll publish separately.)


The decorator feature has become one of the more successful language features, and the 
use of custom decorators has exceeded my widest expectations. Especially web 
frameworks have found lots of uses for them. Based on this success, in Python 2.6, the 
decorator syntax was extended from function definitions to include class definitions.

decorator の機能は more successful な言語機能の一つとなり、カスタム decorators の使用
はわたしの予想を大きくに超えるものとなりました。特に web フレームワークで decprator
の使用例を数多く見つけられます。この成功を受けて Python 2.6においてこの decorator 構文
は、関数定義を対象にしたものからクラス定義を含んだものへと拡張されました。



*Slots (スロット)


Another enhancement made possible with descriptors was the introduction of the 
__slots__ attribute on classes. For example, a class could be defined like this:

ディスクリプターを可能としたもう一つの拡張が、クラスに対する __slots__ 属性の導入でし
た。たとえば、あるクラスは次のように定義できます:


    class C:
      __slots__ = ['x','y']
      ...


The presence of __slots__ does several things. First, it restricts the valid set of 
attribute names on an object to exactly those names listed. Second, since the 
attributes are now fixed, it is no longer necessary to store attributes in an instance 
dictionary, so the __dict__ attribute is removed (unless a base class already has it; 
it can also be added back by a subclass that doesn't use __slots__). Instead, the 
attributes can be stored in predetermined locations within an array. Thus, every slot 
attribute is actually a descriptor object that knows how to set/get each attribute 
using an array index. Underneath the covers, the implementation of this feature is 
done entirely in C and is highly efficient.

The presence of __slots__ does several things.
第一に、あるオブジェクト上の属性名の valid set を本当 (excatly) にその名前がリストにあ
るものに制限しました。第二に、属性は現状で固定されたのでもはやインスタンスの辞書に属性
を格納必要はなくなり、__dict__ 属性も取り除かれました
(unless a base class already has it; 
it can also be added back by a subclass that doesn't use __slots__).

Instead,
the attributes can be stored in predetermined locations within an array.
配列のあらかじめ決められた位置(locations) に属性を格納することが可能でした
Thus,
every slot attribute is actually a descriptor object
このため、すべての slot 属性は
実際にはディスクリプターオブジェクトでした
that knows how to set/get each attribute using an array index.


Underneath the covers,
この機能の実装は完全に C で行われていて非常に効率の良いものでした。


Some people mistakenly assume that the intended purpose of __slots__ is to increase 
code safety (by restricting the attribute names). In reality, my ultimate goal was 
performance. Not only was __slots__ an interesting application of descriptors, I 
feared that all of the changes in the class system were going to have a negative 
impact on performance. In particular, in order to make data descriptors work properly, 
any manipulation of an object's attributes first involved a check of the class 
dictionary to see if that attribute was, in fact, a data descriptor. If so, the 
descriptor was used to handle the attribute access instead of manually manipulating 
the instance dictionary as is normally the case. However, this extra check also meant 
that an extra lookup would be performed prior to inspecting the dictionary of each 
instance. Thus the use of __slots__ was a way to optimize the lookup of data 
attributes―a fallback, if you will, in case people were disappointed with the 
performance impact of the new class system. This turned out unnecessary, but by that 
time it was of course too late to remove __slots__. Of course, used properly, slots 
really can increase performance, especially by reducing memory footprint when many 
small objects are created.

一部の人は __slots__ の意図していた目的が、属性の名前を制限することによってコードの安
全性を増すためであると間違った仮定をしていました。実際にはわたしの最終的な目標はパフォ
ーマンスでした。
Not only was __slots__ an interesting application of descriptors,
ディスクリプターの興味深い応用 (interseting application of descriptors)だけでなく、ク
ラスシステムに対する変更全てがパフォーマンスの面で負の影響 (negative impact) を与える
のではないかということをわたしは心配していました。。

特に、データディスクリプターを適切に動作させるために
in order to make data descriptors work properly, 
any manipulation of an object's attributes first involved a check of the class dictionary
to see if that attribute was, in fact, a data descriptor.

もしデータディスクリプターであったなら、
そのディスクリプターは、インスタンス辞書をマニュアル操作する代わりに通常のケースとして
attribute アクセスの取り扱いに使われました
そうでない場合この extra check は
各インスタンスの辞書の inspecting に先行して
extra lookup が行われることも意味しています。
したがって __slots__ を使うことは、
新しいクラスシステムの performance impact に人々が幻滅してフォールバックしようというときに
データの attribute の lookup を最適化するための手法でした
これは結局不必要なものとなりましたが、
しかしその時点では、__slots__ を取り除くにはもはや手遅れだったのです。
もちろん適切に使うことによって、
特にメモリーのフットプリントを縮小することで大量の小さなオブジェクトが生成される場合に
slots は本当にパフォーマンスを向上させることが可能でした。


I'll leave the history of Python's Method Resolution Order (MRO) to the next post.

Posted by Guido van Rossum at 11:18 AM


■_ 本日の巡回から

2010年06月27日

■_

・みねこあさん
つれづれ - みねこあ まじぽか買ったんですか。あれ何本かいいエピソードがあるんですよね~。 最近出ているこの手のボックスで買おうか悩んでいるのが Amazon.co.jp: 買っ得アニメ!夏のオトナ買いキャンペーン!!『砂ぼうず』DVD BOX(初回限定生産) だったり。 これ、関東だとたしかテレ玉(チバもだったか?)でしか放送しなかったので観られなかったんですよね~。 原作も割りと好きなので是非に…といいつつ2クールものなのでちょっとお高め ○| ̄|_ もうひとつ、こっちはこれからの発売ですが 【秋のオトナ買い】買っ得アニメ!オトナ買いキャンペーン第二弾発売決定!:最新アニメ情報 にある「しにがみのバラッド」が。 こっちは観てましたが(笑)

・黙示録?
ふと気になったのですが、以前にも紹介したページ Apocalisp のタイトルのこれって、「apocalypse」にかけてるんですかね~
地獄の黙示録 特別完全版 [DVD]
と、唐突にアサマシ(原題が「Apocalypse now」)。

・代数学とは何か
ついったーで偶然に引っかかってしったのですが 代数学とは何か | 数学 | 和書 | シュプリンガー・ジャパン という本があるのですね。何ヶ月か前に代数学の本をいろいろ探してみたのですが、 この本はまるきり探索網に引っかかっていませんでした。 いけがみさんの Twitter / Ikegami Daisuke: 圏論までの道が遠いなあ(^^)。これが迂遠なようでま ... を見るに、悪い本ではなさそうなので何とかしたい (図書館のデータベース調べてもやっぱりなかったw)。 7月にかけて、今わかってるだけでも結構あるしなあ。 オライリーの本で、 イベントでの出張販売で買おうと目論んでいる(ノベルティ目当てw) のもあるしなあ。 この辺→ O'Reilly Japan - デコンパイリングJava O'Reilly Japan - リバースエンジニアリング O'Reilly Japan - 正規表現クックブック O'Reilly Japan - ビューティフルセキュリティ
Erlangプログラミング 978-4-87311-465-1 ¥3,780 2010年07月
初めてのコンピュータサイエンス 978-4-87311-463-7 ¥2,520 2010年07月

■_ 十個の質問

最初に見かけてから二日ほど放置していましたが、いい感じにスレッドが伸びているようです。


Ten Ugly Lisp Data Type Questions : lisp
  1. Why is there no freakin' copy operation for arrays? (なぜ配列のための freakin' なコピー操作がないの?)
  2. Why is there no freakin' copy operation for hashtables? (なぜハッシュテーブルのための以下略)
  3. What possible use is there for vector-push? Has anyone ever used it instead of vector-push-extend?
  4. Why are there literals for (extensible) lists but not for extensible vectors? (なぜ(拡張可能な)リストのためのリテラルはあるのにベクターのためのそれはないの?)
  5. Why do some predicates end in p, others end in -p, and still others (notably null and atom) end in whatever they feel like? Seriously: the test for vectors is vectorp, but the test for simple vectors is simple-vector-p. I mean, really. (なぜ一部の述語 (predicates) は pで終わり、別のものは -p で終わり、さらには 好きなようなもので終わっているもの(特に null と atom) があるのはなぜ? )
  6. Why can you deep-copy a list but not a vector, array, or hash table? (なぜリストのディープコピーはできるのに、ベクターや配列、ハッシュテーブルに対してはできないの?)
  7. Why do you make arrays with make-array, strings with make-string, hash tables with make-hash-table, but there's no make-vector or make-simple-vector? (なぜ配列を make-array で、文字列を make-string で、ハッシュを make-hash-table で生成するのに、 make-vector や make-simple-vector がないの?)
  8. Why does the vector function make simple vectors? Shouldn't it be making general purpose extensible vectors? (なぜ vector 関数は単純なベクターを生成するの? 拡張可能なベクターのために一般的なものにすべきでは?)
  9. Why, oh why, is the default test for make-hash-table #'eql? (なんでまた make-hash-table のデフォルトのテストが #'eql なんですか?)
  10. Why is there a dolist but no doseq or dohashtable? (dolist があるのに、doseq や dohashtable がないのはなぜ?)

コメントでどんなのがあるか後で見てみよう。

■_ カッとして

その2。 イキオイでざっくりやっただけでほとんど見直しもしていません。 resolution はまあ「解決」なんでしょうが、 ひねりを加えてバックドロップしています。


The History of Python: Method Resolution Order

The History of Python

A series of articles on the history of the Python programming language and its community.

Wednesday, June 23, 2010

Method Resolution Order
(メソッドの名前解決の順序)

In languages that use multiple inheritance, the order in which base classes are 
searched when looking for a method is often called the Method Resolution Order, or MRO. 
(In Python this also applies to other attributes.) For languages that support single 
inheritance only, the MRO is uninteresting; but when multiple inheritance comes into 
play, the choice of an MRO algorithm can be remarkably subtle. Python has known at 
least three different MRO algorithms: classic, Python 2.2 new-style, and Python 2.3 
new-style (a.k.a. C3). Only the latter survives in Python 3.


多重継承を使用している言語での、メソッドを探索するときのそのベースクラス群が検索される
順序は Method Resolution Order, あるいは略して MRO (メソッド解決順序とでも? イマイチ)
のようにしばしば呼ばれています (In Python this also applies to other attributes)。単一
継承だけをサポートしている言語ではこの MRO は面白いものではありません。しかし多重継承
がここに絡んでくると、MRO アルゴリズムの選択は remarkably subtle になる可能性があり
ます。Python では、伝統的なもの (classic)、Python 2.2 の新形式 (new-style)、そして 
Python 2.3 の新形式 (a.k.a. C3) の少なくとも三つの異なる MRO アルゴリズムが知られてい
ます。後のものだけが Python 3でも生き残りました。


Classic classes used a simple MRO scheme: when looking up a method, base classes were 
searched using a simple depth-first left-to-right scheme. The first matching object 
found during this search would be returned. For example, consider these classes:

クラシッククラス (classic class) ではメソッドの検索を行うときに、ベースクラス群を単純
な深さ優先で left-to-right な手順で検索する単純な MRO 手法を採用していました。これは検
索中に最初に見つかったオブジェクトが返されます。たとえば次のようなクラス群を考えます:

    class A:
       def save(self): pass

    class B(A): pass

    class C:
       def save(self): pass

    class D(B, C): pass

If we created an instance x of class D, the classic method resolution order would 
order the classes as D, B, A, C. Thus, a search for the method x.save() would produce 
A.save() (and not C.save()). This scheme works fine for simple cases, but has problems 
that become apparent when one considers more complicated uses of multiple inheritance. 
One problem concerns method lookup under "diamond inheritance." For example:

クラス D のインスタンス x を生成したとすると、classic なメソッド解決順では D→B→A→C
という検索順序になります。したがって、メソッド x.save() に対する探索は A.save() を生成
します(そして C.save()は生成しません)。この手法は単純なケースに対してはうまくいきます
が、多重継承を使ったもっと複雑なものを考慮したときに問題があることが明かになります。


One problem concerns method lookup under "diamond inheritance"
("diamond inheritance" (ダイヤモンド継承)下でのメソッド検索)

例を挙げましょう:

    class A:
       def save(self): pass

    class B(A): pass

    class C(A):
       def save(self): pass

    class D(B, C): pass

Here, class D inherits from B and C, both of which inherit from class A. Using the 
classic MRO, methods would be found by searching the classes in the order D, B, A, C, 
A. Thus, a reference to x.save() will call A.save() as before. However, this unlikely 
want you want in this case! Since both B and C inherit from A, one can argue that the 
redefined method C.save() is actually the method that you want to call, since it can 
be viewed as being "more specialized" than the method in A (in fact, it 
probably calls A.save() anyways). For instance, if the save() method is being used to 
save the state of an object, not calling C.save() would break the program since the 
state of C would be ignored.

ここに、両方ともがクラス A から継承しているクラス B とクラス C から継承したクラス D が
あります。classic MRO を使ったとすると、メソッドは D→B→A→C→Aの順にクラスを検索して
いって(最初に)見つかったものになりますしたがって x.save()に対する参照は事前に A.save()
を呼び出すことになります。しかしこれはこのケースであなたが望んでいたものとは違うのです! 
B と C の両方が A から継承しているので、再定義されたメソッド C.save() が実際にあなたが
呼び出したいと考えていたメソッドであると主張することも可能です。これは A にあるメソッ
ドよりも "more specialized" (さらに特殊化されたもの)と見ることも可能だからと
理由もあります (事実、このメソッドは A.save() を何らかの形で呼び出します)。たとえば 
save()メソッドがあるオブジェクトの状態を保存するために使われているものだとすると、
C.save() を呼び出さないことは C の状態が無視されれることになるのでプログラムを破壊して
しまうでしょう。

#なんだよ Since ..., ..., since. ... って

Although this kind of multiple inheritance was rare in existing code, new-style 
classes would make it commonplace. This is because all new-style classes were defined 
by inheriting from a base class object. Thus, any use of multiple inheritance in 
new-style classes would always create the diamond relationship described above. For 
example:

この種の多重継承は既存のコードではほとんど見られなかったにも関わらず、新形式のクラスは
これ (多重継承) をありふれたものにしてしまいました。これはすべての新形式クラスがベース
クラスオブジェクトから継承することによって定義されていたからです。つまり、新形式クラス
で多重継承を使ったものはすべて、常に前述した diamond relationship を作り出すのです。
For example:

    class B(object): pass

    class C(object):
       def __setattr__(self, name, value): pass

    class D(B, C): pass

Moreover, since object defined a number of methods that are sometimes extended by 
subtypes (e.g., __setattr__()), the resolution order becomes critical. For example, in 
the above code, the method C.__setattr__ should apply to instances of class D.

それに加えて、オブジェクトはサブタイプ (e.g., __setattr__()) によって extended される
こともあるメソッドをたくさん定義しているので、その探索順序が重要になります。たとえば先
のコードでは、C.__setattr__ メソッドはクラス D のインスタンスに対して適用すべきです。


To fix the method resolution order for new-style classes in Python 2.2, I adopted a 
scheme where the MRO would be pre-computed when a class was defined and stored as an 
attribute of each class object. The computation of the MRO was officially documented 
as using a depth-first left-to-right traversal of the classes as before. If any class 
was duplicated in this search, all but the last occurrence would be deleted from the 
MRO list. So, for our earlier example, the search order would be D, B, C, A (as 
opposed to D, B, A, C, A with classic classes).


Python 2.2において新形式クラス向けのメソッド探索順序を修正するために、わたしはクラスが
定義されたときに事前計算 (pre-computed) が行われて各クラスオブジェクトの属性として格納
されるような手法を採用しました。MRO の計算手法は、前述したような depth-first 
left-to-right traversal of the classes (クラス群のトラバーサルを深さ優先、左から右への
順で行う)を使っていると公式にドキュメント化されていました。この検索において何らかのク
ラスが重複していたならば、そのうちの最後に出現したもの以外はMROリストから削除されます。
ですから先の例で言えば、検索順序は D→B→C→A となります(対照的にclassic classに対して
はD→B→A→C→A)。

In reality, the computation of the MRO was more complex than this. I discovered a few 
cases where this new MRO algorithm didn't seem to work. Thus, there was a special case 
to deal with a situation when two bases classes occurred in a different order in the 
inheritance list of two different derived classes, and both of those classes are 
inherited by yet another class. For example:

実際には MRO の計算はこれよりもずっと複雑なもので、わたしは新しいMROアルゴリズムがうま
く動作していないように思われる少数のケースを発見しました。つまり、別々な二つの派生クラ
スの継承リスト中で二つのベースクラスが異なる順序で出現していて、さらにそれらのクラス両
方ともがさらに別のクラスから継承しているといったシチュエーションを扱うための特別なケー
スが存在していたのです。


For example:

たとえば:

    class A(object): pass
    class B(object): pass
    class X(A, B): pass
    class Y(B, A): pass
    class Z(X, Y): pass

Using the tentative new MRO algorithm, the MRO for these classes would be Z, X, Y, B, 
A, object. (Here 'object' is the universal base class.) However, I didn't like the 
fact that B and A were in reversed order. Thus, the real MRO would interchange their 
order to produce Z, X, Y, A, B, object. Inituitively, this algorithm tried to preserve 
the order of classes for bases that appeared first in the search process. For instance, 
on class Z, the base class X would be checked first because it was first in the 
inheritance list. Since X inherited from A and B, the MRO algorithm would try to 
preserve that ordering. This is what I implemented for Python 2.2, but I documented 
the earlier algorithm (naïvely thinking it didn't matter much).

これらのクラスに対する MRO は Z→X→Y→B→A→object となります(ここで 'object' は 
universal なベースクラスです)。しかし、このとき B と Aが逆順に現れるという点がわたしは
好きではなかったのです。このため、実際のMROでは Z, X, Y, A, B, object という順序にする
ためにその探索順序を interchange (交換)していました。
Inituitively,
# スペルミス?
このアルゴリズムでは、その検索プロセスにおいてベースとなるクラスの最初に出現した順序を
保存することを試みます。たとえば、クラス Zに対してそのベースクラス X が最初にチェック
されます。なぜならこのクラスが継承リストの最初にあるからです。X は A と B から継承して
いるので、MRO アルゴリズムではこの順序を保存しようとします。これが Python 2.2 のために
わたしが実装したものですが、わたしは earlier algorithm をドキュメントに記載していまし
た (naively thinking it didn't matter much)。

However, shortly after the introduction of new-style classes in Python 2.2, Samuele 
Pedroni discovered an inconsistency between the documented MRO algorithm and the 
results that were actually observed in real-code. Moreover, inconsistencies were 
occurring even in code that did not fall under the special case observed above. After 
much discussion, it was decided that the MRO adopted for Python 2.2 was broken and 
that Python should adopt the C3 Linearization algorithm described in the paper "A 
Monotonic Superclass Linearization for Dylan" (K. Barrett, et al, presented at 
OOPSLA'96).

しかし Python 2.2 で新形式クラスを導入してすぐあとに、Samluele Pedroni がドキュメント
に記載されていたMROアルゴリズムと実際のコードで得られた結果との間の一貫性の欠如を発見
したのでした。さらに一貫性の欠如が、先に説明した特殊なケースに当てはまらないコードでさ
えも発生していました。多くの議論の後、Python 2.2で採用された MRO はbroken であり、
Python では "A Monotonic Superclass Linearization for Dylan"
(K. Barrett, et al, presented at OOPSLA'96)
という論文に記載されている C3 Linearization アルゴリズムを採用すべきであるという
結論になりました。


Essentially, the main problem in the Python 2.2 MRO algorithm concerned the issue of 
monotonicity. In a complex inheritance hierarchy, each inheritance relationship 
defines a simple set of rules concerning the order in which classes should be checked. 
Specifically, if a class A inherits from class B, then the MRO should obviously check 
A before B. Likewise, if a class B uses multiple inheritance to inherit from C and D, 
then B should be checked before C and C should be checked before D.

本質的には、Python 2.2における MROアルゴリズムの主問題は issue of monotonicity に関係
しています。複雑な継承階層の中では、チェックすべきクラスの順序に関する規則の単純な集ま
りを定義します。具体的にはあるクラス B から継承したクラス Aがあったとき、MRO は明らか
に Bよりも前に Aをチェックすべきです。同様に、あるクラス B がクラス C とクラス Dから継
承するために多重継承を使っているならば、B は C より前にチェックされるべきであり、C は 
Dよりも前にチェックすべきなのです。

Within a complex inheritance hierarchy, you want to be able to satisfy all of these 
possible rules in a way that is monotonic. That is, if you have already determined 
that class A should be checked before class B, then you should never encounter a 
situation that requires class B to be checked before class A (otherwise, the result is 
undefined and the inheritance hierarchy should be rejected). This is where the 
original MRO got it wrong and where the C3 algorithm comes into play. Basically, the 
idea behind C3 is that if you write down all of the ordering rules imposed by 
inheritance relationships in a complex class hierarchy, the algorithm will determine a 
monotonic ordering of the classes that satisfies all of them. If such an ordering can 
not be determined, the algorithm will fail.

あなたは 複雑な継承階層に対して monotonic (単調?) なやり方でこれらの可能な規則をすべて
満足することを可能にするのを望んでいます。つまり、もしあなたがすでにクラス A はクラス 
Bより前にチェックすべきであるということを決定していたのならば、その後でクラスBをクラス
Aより先にチェックすることを要求するシチュエーションに決して遭遇すべきでないということ
なのです(さもなければ、その結果は未定義でありその継承階層は reject すべきです)。これが
オリジナルの MRO アルゴリズムが間違っていた点であり、C3 アルゴリズムがその能力を発揮し
ている点です。基本的に C3 の背景にあるアイデアは、もし複雑なクラス階層中の継承関係によ
ってimpose される順序づけ規則群 (ordering rules)を書き下せれば、そのアルゴリズムはそれ
らすべてを満足するクラスの monotonic な順序を決定するだろうというものです。そういった
順序づけ (ordering) が決定できない場合がありえるならばそのアルゴリズムは失敗します。


Thus, in Python 2.3, we abandoned my home-grown 2.2 MRO algorithm in favor of the 
academically vetted C3 algorithm. One outcome of this is that Python will now reject 
any inheritance hierarchy that has an inconsistent ordering of base classes. For 
instance, in the previous example, there is an ordering conflict between class X and Y. 
For class X, there is a rule that says class A should be checked before class B. 
However, for class Y, the rule says that class B should be checked before A. In 
isolation, this discrepancy is fine, but if X and Y are ever combined together in the 
same inheritance hierarchy for another class (such as in the definition of class Z), 
that class will be rejected by the C3 algorithm. This, of course, matches the Zen of 
Python's "errors should never pass silently" rule.

このため Python 2.3では、わたしたちはわたしの home-grown 2.2 MRO アルゴリズムを諦めて、
学術的に精査された(academically vetted) C3 アルゴリズムを支持したのです。これによりベ
ースクラスに一貫していない順序をもったすべての継承階層をPython が弾く(reject) ようにな
りました。たとえば先の例で考えると、クラス X とクラス Yとの間で順序づけの衝突が存在し
ます。クラス Xに対してはクラスAはクラスBの前にチェックすべきであると主張する規則が存在
します。しかしクラスYに対しては、クラスBをクラスAよりも前にチェックすべきだとする規則
があるのです。これらのクラスが分離されているのであればこの discrepancy (不一致、食い違
い) には問題ありません。しかし仮に X と Y が (たとえばクラス Z での再定義のように)別の
クラスに対して、同じ継承階層 (inheritance hierarchy) 上で結びつけられているのであれば、
そのようなクラスはC3 アルゴリズムによって reject されるでしょう。もちろんこれは、Zen 
of Python のいう  "errors should never pass silently" (エラーはこっそりと
スルーすべきではない) ルールにも合致するものです。

Posted by Guido van Rossum at 10:41 AM


■_ 惜しいことをした

偶然見つけたスレで

トラベラー総合スレ その2 
198 NPCさん [] 2010/05/23(日) 20:56:33 ID:nEAeFQoh Be:
    転居で引っ越す事になって箱モノTRPGごそっと処分しなくちゃいけなくなった。
    HJ版トラベラー+エクスパンション欲しい人いるだろうか。
    古本屋だと叩き値にもならなくて悔しい・・・ 

199 NPCさん [sage] 2010/05/23(日) 21:43:09 ID:??? Be:
    >>198
    うほっ

    興味ありんす 

200 NPCさん [sage] 2010/05/23(日) 22:33:30 ID:??? Be:
    アッー
    それはボクも欲しいね! 

201 NPCさん [sage] 2010/05/24(月) 03:08:46 ID:??? Be:
    >>198
    レフェリーズ・アクセサリーとロボットマニュアルがとても 

202 NPCさん [sage] 2010/05/24(月) 03:54:28 ID:??? Be:
    >>198
    ただとは言わんから売ってくれ 

203 NPCさん [sage] 2010/05/24(月) 08:56:15 ID:??? Be:
    オクに出したらそれなりの値段になるんじゃない? 

204 198です [] 2010/05/24(月) 18:08:58 ID:YgsVmGFO Be:
    >>199-203
    レスどもです。
    「基本セット」「HighGuard」のボックスと
    「傭兵部隊」「ブロードソード」「ベテラン」「Long way home(英語版)」
    「黄昏の峰へ」「帝国市民」「デスステーション・アルゴンギャンビット」
    「GDW版メガトラ(1版/英語)」が完品でありました。

    スレチ承知なんですけど適正な価値ってどんなもんなんでしょう?
    オクは以前酷い詐欺に遭って依頼敬遠しとるので  

205 NPCさん [sage] 2010/05/25(火) 00:10:33 ID:??? Be:
    >>204
    イエサブかかえる堂で買取してるぞ、ボッタだけど。
    素直にオクが一番賢いと思うんだがその前にたそみねだけ俺にくれ 

206 NPCさん [sage] 2010/05/25(火) 00:36:21 ID:??? Be:
    黄昏の峰除いたら一気にゴミ化する醤w

    それはともかく、i-OGMでも買取やっているね。
    経験は購入だけだけど、あそこはゲーマー寄りでいい店(買い取り価格は安いかもしれんが)。 

207 NPCさん [sage] 2010/05/25(火) 01:30:04 ID:??? Be:
    HJ版のHighGuardって海軍/キンキ/一兆だっけ? 

208 NPCさん [sage] 2010/05/25(火) 22:54:49 ID:??? Be:
    結局「スタートセット」と「宇宙海軍」が箱付きで
    「黄昏の峰へ」「傭兵部隊」が箱なしって事になるんかな? 

209 198です [sage] 2010/05/26(水) 18:29:51 ID:??? Be:
    >>207はい、そうです。
    >>208そうです。近所の古本屋で全部合わせて¥610って言われました(´;ω;`) 

210 NPCさん [sage] 2010/05/26(水) 20:33:04 ID:??? Be:
    >>209
    それは安すぐるw
    とはいえ頻繁に流通してるモノじゃ無いから適正な価格とかワカランなぁ 

211 198です [sage] 2010/05/26(水) 20:56:47 ID:??? Be:
    >>210
    思い出と愛着で補正かかってたんでショックでしたw

    あれから調べてみましたがTRPG扱ってるネット買取だとどこも
    1セット¥1500位(実際は傷アリとかで¥500位)でした。こんなものなのでしょうかね。 

212 NPCさん [sage] 2010/05/26(水) 21:48:59 ID:??? Be:
    じゃあ、箱無し傭兵部隊 (傭兵部隊、ブロードソード、ベテランのセット) を 2000円で買います。
    よっぽど破れたり書き込みまくったりしてなければ、少々ボロでも構いません。
    当方、神奈川在住。
    首都圏在住であれば手渡し OK です。

213 NPCさん [sage] 2010/05/27(木) 04:18:33 ID:??? Be:
    むかし手放して、再入手しそこなっていたので、興味津々。

    どれも魅力的だが、手が挙がってないのは「基本セット」「HighGuard」「帝国市民」「デスステーション・アルゴンギャンビット」か。

    値段が折り合いつけば、一口乗りたいなあ。 

214 NPCさん [sage] 2010/05/27(木) 11:49:06 ID:??? Be:
    まとめて5~6kくらいなら欲しいかも
    興味あるのは基本=ハイガ>峰>傭兵>その他の順かな 

215 198です [kyougoku@kxa.biglobe.ne.jp] 2010/05/27(木) 18:00:07 ID:??? Be:
    >>212-214 Σ(゚△゚)
    有益情報やご提案ありがとうございます!
    ・・・でもこのスレでこれ以上の私事はいかんと思うので
    以降はメ欄までお願いします。本当に皆さんありがとうございます 

216 NPCさん [sage] 2010/05/28(金) 03:40:43 ID:??? Be:
    >>215
    リスト見たけど>>198にも俺らにも良心的な相場なんじゃね?
    トラ以外のレトロBOX見る限りかなりの古参だとオモタw 

218 NPCさん [sage] 2010/05/29(土) 08:59:55 ID:??? Be:
    嫁入り先はもう見つかったかな? 

221 >>198です [sage] 2010/05/30(日) 16:59:33 ID:??? Be:
    >>212さんに「傭兵部隊」3冊、>>219さんに赤箱セットとFRtRお譲りする
    事になりました。親切なメール下さってありがとうございます。

    >>213>>214
    基本セット/宇宙海軍/黄昏はまだ確保してます。希望されるなら連絡待ってます 

229 NPCさん [sage] 2010/06/07(月) 14:47:27 ID:??? Be:
    >>198
    赤箱+FRR無事届いた。大事に使うよありがとう! 

230 NPCさん [sage] 2010/06/07(月) 21:54:48 ID:??? Be:
    >>229
    結局いくらで買ったの? 

231 NPCさん [sage ] 2010/06/08(火) 00:12:06 ID:??? Be:
    ありえない程お値打ち価格だった、とだけ言っておく 

232 NPCさん [sage] 2010/06/08(火) 17:55:07 ID:??? Be:
    いいなぁ
    もう少し早くこのスレ見つけてればよかった>< 

233 198です [sage ] 2010/06/08(火) 18:32:53 ID:??? Be:
    >>212さん>>231さん
    身請けありがとうございました。どちらも無事に届いたようで丁寧な対応に感謝です。
    アドバイス頂いたスレの皆さんもありがとうございます。

    >>232
    │ω・)実はまだ在庫結構あるんで欲しいのがあればご連絡お待ちしておるですよ。
    と  詳しくは>>215参照。転居する月末までは連絡つきます

    ※旧トラ関係は現在楽天オクに出しております 


なんで「黄昏の峰へ」の人気が高いのかわからんけど、 「宇宙海軍」がががが。 「一兆クレジット艦隊」はこれに収録されてんだよねえ。

■_ 本日の巡回から

2010年06月26日

■_

・「記号と再帰」
高橋会長のRTで知り、 Twitter / flurry: えらいことになっている。>東京大学出版会 『記号と再 ... Twitter / Urabe, Shyouhei: 「記号と再帰」おお、この本にはきちんと「型とは何か」 ... 見逃せない気配を感じたので買ってきました。
記号と再帰―記号論の形式・プログラムの必然
散々探して「哲学」のコーナーで発見 ○| ̄|_

んで、適当に拾い読みしてたんですが、ちょっと気になる記述が。

p125 欄外脚注
17) 本章でも「参照渡し」において同じ「参照」が用いられたように、情報科学・技術の分
野では、アドレスのことを「参照」ということがある。
  
p117
関数が値渡しか参照渡しかは、再び文脈により実用論的に決まり、今回の場合は、引数の型
で決まる。2.4.2節で述べたように、Javaの型は言語使用上事前に定義され導入されている
基本型と、  ライブラリや個別プログラムでプログラマが定義して導入する複合型の二つが
ある。Javaでは、基本型は値として扱われ、複合型の場合はアドレスとして扱われる。この
仕様は関数の引数でも同様に考えられており、引数が基本型の場合には値渡し、複合型は参
照渡しである。

筆者が断り書きをしている内容に従えばまあそうなんですが、 Javaはプリミティブ型でなくても「call by value」(値呼び出し、値渡し)が 使われるというのは言語仕様にあったような気がするんですが。 「参照渡し」を実装したときに「アドレス」を渡すような実装が多いからといって 参照 == (変数の)アドレス ではないし、引数が書き換えられるから 参照を渡しているということではないんですけどねえ。 とまたも重箱の隅に気を取られちゅー。

・ブラクラ
tvk でOVA一巻を(一部カットして)放映したのを観た。 やっぱ買わねば。

■_ 本日の巡回から

■_ innner function

スレ立てるまでもない質問はここで 106匹目 
123 デフォルトの名無しさん [sage] 2010/06/21(月) 22:41:53 ID: Be:
    なんでローカル関数って無いんですか?

    普通に考えたら、スコープを広げたらだめでしょ。 

124 デフォルトの名無しさん [sage] 2010/06/21(月) 22:49:17 ID: Be:
    >>123
    どの言語の話?
    ローカル関数が欲しいならクロージャがあるけど 

125 デフォルトの名無しさん [sage] 2010/06/21(月) 23:01:08 ID: Be:
    一つの関数が長いってだけで、
    メソッドにするのはバカだと思う。

    関数が長ければ、ローカル関数にすべき。 

126 デフォルトの名無しさん [sage] 2010/06/21(月) 23:01:27 ID: Be:
    ローカル関数のある言語くらいいくらでもあるけど
    C言語のことかね
    ローカル変数へのアクセスを許すか否か、
    許すとして、ローカル変数をローカル関数外で変更した際に
    追従するかしないかなど、気をつける点が色々とあるからじゃないかね

    C++なら関数内にローカルクラス作って
    その中にstaticメンバ関数作れば
    ローカル関数を作る事は一応できる(ローカル変数に触れないけど)
    C++0xからはラムダを利用してローカル関数のようなものが作れる 

127 デフォルトの名無しさん [sage] 2010/06/21(月) 23:05:09 ID: Be:
    あとは、ローカル関数の関数ポインタをどうするか、というのもあるはず
    ローカル変数に触れないならこの点問題ないんだけど、
    触れる場合は問題になる
    関数コール時にローカル変数に関する情報を渡さないといけないけど、
    関数ポインタ(要するに単なる関数へのアドレス)だけだとそういった情報がない

    このあたり、C++0xのラムダでは、
    ローカル変数に触らないラムダだけは関数ポインタに変換できるようにする、
    という提案が出ている 


まあ gcc で 外側のスコープにある変数二アクセスするような inner function を使った簡単なプログラムを書いて、 そのアセンブリコードを眺めてみるとなんでこんなしちめんどくさいことをやってんだ というコードが吐かれているはず (バージョンが上がっても多分その辺の方針は変わってないだろう)。

■_ カッとなってやった

反省はしていない。

The History of Python: New-style Classes
The History of Python

A series of articles on the history of the Python programming language and its community.

Monday, June 21, 2010

New-style Classes
新形式のクラス


[After a long hiatus, this blog series is back! I will continue where I left off last 
year. I'll try to keep the frequency up.]

Earlier, I described how the addition of classes to Python was essentially an 
afterthought. The implementation chosen was definitely an example of Python's 
"cut corners" philosophy. However, as Python evolved, various problems with 
the class implementation became a popular topic of griping from expert Python users.

以前にわたしは、Python に対するクラスの追加がどれほど本質的には後付けなものであったの
かを説明しました。実装の選択は明らかにPython の "cut corners" (手抜きをする、
労力を節約して容易な手法を使う) 哲学の実例でした。しかしながら Python の発展(進化)と共
に、クラスの実装に関する様々な問題が Pythonユーザーたちのうちエキスパートである連中の
関心を惹きつけたpopular なトピックとなったのです。

One problem with the class implementation was that there was no way to subclass 
built-in types. For example, lists, dictionaries, strings, and other objects were 
somehow "special" and could not be specialized via subclassing. This 
limitation seemed rather odd for a language that claimed to be "object oriented."

この、クラスの実装に関する問題の一つが組み込み型 (built-in types) のサブクラスを作る
手段がなかったということです。たとえば、リスト、辞書、文字列その他のオブジェクトはある
種“特殊”なものであって、サブクラス化を使っての特殊化 (specialized via subclassing)
ができませんでした。この制限は、“オブジェクト指向”であると主張する言語としては非常
に奇異なものに見えたようです。


Another problem was that whole type system just seemed to be "wrong" with 
user defined classes. For example, if you created two objects a and b, statements such 
as type(a) == type(b) would evaluate as True even if a and b were instances of 
completely unrelated classes. Needless to say, developers who were familiar with 
languages such as C++ and Java found this be rather odd since in those languages, 
classes were tightly integrated with the underlying type system.

もうひとつの問題は、型システム全体がただ単にユーザー定義型のクラスに対して“適切でない”
(wrong) ように思われたことです。たとえば a と b という二つのオブジェクトを作ったとする
と、たとえ a と b がまったく関係のないクラスのインスタンス同士であったとしても
type(a) == type(b) といった文の評価結果が True になってしまうのです。いうまでもないこ
とですが、C++ や Java のような言語に慣れ親しんでいた開発者たちはそういった言語ではクラ
スはその型システムの下に強固に結び付けられていた (tightly integerated) ので、Python
のこの振る舞いが奇妙であることに気がつきました。

In Python 2.2, I finally took the time to reimplement classes and "do it 
right." This change was, by far, the most ambitious rewrite of a major Python 
subsystem to date and one could certainly accuse me of a certain amount of 
"second-system syndrome" in this effort. Not only did I address the 
immediate problem of allowing built-in types to be subclassed, I also added support 
for true metaclasses, attempted to fix the naïve method resolution order for multiple 
inheritance, and added a variety of other features. A major influence on this work was 
the book "Putting Metaclasses to Work" by Ira Forman and Scott Danforth, 
which provided me with a specific notion of what a metaclass is, different from a 
similar concept in Smalltalk.

Python 2.2 でようやくわたしはクラスを再実装するための時間を作り出し、"do it right."
(正しく行うようにしたのです)。この変更は今日に至るまでの、Python の主要なサブシステム
に対する最も野心的な書き換えでしたし、誰かがこの労力に対して、"second-system 
syndrome" (セカンドシステムシンドローム)であるとわたしを責めることもできるでしょ
う。組み込み型のサブクラス化を可能にするために差し迫った問題に対処するだけでなく、本当
のメタクラスのサポートも追加したり多重継承のためのネイティブメソッドの解決の修正を試み、
そのほかさまざまな機能を追加しました。この作業の大きな (major) 影響は Ira Forman と
Scott Danforth による "Putting Metaclasses to Work" という本が、
Smalltalk の同様のコンセプトを持ったそれとは異なったメタクラスの明確な概念をわたしに
教えてくれたことです。

# なーした日記: セカンドシステム症候群(second system syndrome)


An interesting aspect of the class rewrite was that new-style classes were introduced 
as a new language feature, not as a strict replacement for old-style classes. In fact, 
for backwards compatibility, the old class implementation remains the default class 
creation protocol in Python 2. To create a new-style class, you simply have to 
subclass an existing new-style class such as object (which is the root for the 
new-style class hierarchy). For example:

クラスの書き直しについての興味深い一側面は、新形式のクラスは言語の新機能として導入され
たもので旧形式のクラスの厳密な置き換えとしてではなかったということです。事実、後方互換
性のためにPython 2.x でのデフォルトのクラス生成プロトコルとして古いクラスの実装も残さ
れていました。新形式クラスを生成するには、object (新形式クラスの階層のルートに位置する
ものです) のような既存の新形式クラスのサブクラスとする必要があります。
たとえば:

    class A(object):
      statements
      ...


The change to new-style classes has been a major success. The new metaclasses have 
become popular amongst framework writers and explaining classes has actually become 
easier since there were fewer exceptions. The fact that backwards compatibility was 
maintained meant that old code has continued to work as new-style classes have evolved. 
Finally, although the old-style classes will eventually be removed from the languages, 
users are getting used to writing "class MyClass(object)" to declare a class, 
which isn't so bad.


新形式クラスへの変更は大きな成功 (major success) を収めました。新しいメタクラスはフレ
ームワークのライターたちの間で popular なものとなりましたそしてクラスの explaining (説
明?)は例外の数がごく少数であったので、格段に簡単なものになりました。後方互換性が、新形
式のクラスと同じように古いコードも動作し続けるように手を入れることを意味している事実が
導き出されました。最終的に旧形式のクラスは言語から取り除かれたにも関わらず、ユーザーは
クラスを宣言するのに (新形式クラスの記法である) "class MyClass(object)"と書
き続けていますが、これはそれほど悪いことではないでしょう。


Posted by Guido van Rossum at 11:07 AM

2010年06月25日

■_

・ダムエー
なるほどそうきたか>オリジン

・アフタヌーン
ヴィンランド・サガは今月もお休み。 ちごぷりが最終回。 ラブやんが次回で100回。

壁紙取り損ねた…24時間限定配信なんて○| ̄|_ (終わってから知った)

■_


Journal of chromatic (983)

The Perl 6 design team met by phone on 09 June 2010. Larry, Allison, Patrick, and chromatic attended.

Larry:

    * not much spec change this week
    * figured out a syntax for a regex block to return more than one cursor
    * based on gather/take
    * in STD hacking, continued to assist Stefan O'Rear in getting STD bootstrapped via viv
    * now that it's bootstrapped, we're refactoring things that make sense now
    * we're now starting to move bits of Cursor code from Perl 5 into Perl 6
    * refactoring the grammar for sanity of design
    * started upgrading STD to normal Perl 6 syntax where it previously catered to gimme5's
      limitations
    * for example, switched STD's old .<_from> and .<_pos> hash lookups to
      using .from and .pos accessors
    * started the prep work for moving EXPR out of STD to make it generally available to
      any grammar wanting operator precedence
    * in STD parsing, made Perl 5 $< detection have a longer token to avoid confusion
      with match variables
    * STD no longer attempts two-terms detection on infix_circumfix_meta_operator
    * STD now parses >>R~<< correctly, or at least dwimmily
    * STD doesn't complain about P5isms in printf formats like "%{$count}s"
    * STD was parsing /m and /s with the opposite semantics
    * termish now localizes $*MULTINESS in its scope so that inner declarations aren't
      accidentally multified
    * STD now carps about package Foo; as a Perl 5 construct

ハッシュのルックアップが変わってる? .<_from> and .<_pos> hash lookups to using .from and .pos accessors まあアングルブラケットを入力するのにはシフトキーも押さないといけないもんなあ。

■_ なんだこれ

もうひとつ Perl 6ネタ。


Euler #2 « Just Rakudo It
Just Rakudo It
I Never Metaop I Didn't Like
« Trig Tests
Euler #2
By colomon

Just saw a nice post with solutions to Euler problem #2 in several different languages.

    Each new term in the Fibonacci sequence is generated by adding the previous two 
    terms. By starting with 1 and 2, the first 10 terms will be:

    1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …

    Find the sum of all the even-valued terms in the sequence which do not exceed four 
    million.

This one is so easy in Perl 6 it’s not worth writing a script, I just did it as a 
one-liner in the REPL:

> say [+] (1, 1, *+* ... 4000000).grep(* !% 2)
4613732

Breaking it down: 1, 1, *+* ... * is the standard way to generate the infinite 
Fibonacci sequence in p6. It creates a list of numbers using the ... “series” 
operator. The list starts with 1, 1, and each additional number is created by adding 
the two previous numbers (that’s the *+* bit). The final * means the series has no 
limit. By switching the limit to 4000000 instead, we explicitly say “stop the series 
as soon as the number 4000000 is exceeded.”

> say ~(1, 1, *+* ... 4000000)
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946 17711 28657 46368 75025 121393 196418 317811 514229 832040 1346269 2178309 3524578

Then grep filters on the test * !% 2. !% is the “divisible by” operator; * !% 2 
generates a closure that checks its one input for divisibility by 2.

(以下略)

*+* ってなんじゃと思ったらプレースホルダーみたいなもの? でもこれ前後で別のもの指してないとフィボナッチ数列を得られないよねえ。

■_ 毎度のことだけど

日本語版の記述にはぐんにょりだなあ>うぃきぺ


数字<英字 とは限りません。
数字<英字 とは限りません。

オープン系開発者は、文字コードのベースが ASCIIコードの人が多いので、無意識の内に数字
<英字と反応するようです。暗黙知になっている人もいます。

  '0'<'9'<'A'<'a' です。
で
  も、汎用機で使われている EBCDICコードでは '英字'<'数字'です。 'A'<'0'です。
これが小さな騒動になったりするので、暗黙知に差があると怖い。
商品コード順のリストなどで、コードが英数字で構成されているとき、ソート結果の順序が、汎
用機での出力結果と、Open系での結果や、Excelでのソート結果では、並び順が異なります。

(略)

  EBCDICコード系をみる度に、「策定者は(将来のことを)深く考えなかった。」と思えてしかた
  がありません。

投稿日時 : 2010年6月25日 0:44
Feedback
# re: 数字<英字 とは限りません。 2010/06/25 1:51 aetos

> EBCDIC (Extended Binary Coded Decimal Interchange Code) はIBMにより定義された文字コードである。

- Wikipedia より。

何と言いますか、「またIBMか」という感じが。

ASCIIコードと互換性のないEBCDICコードを作ったのもIBMなら、アメリカのキーボードをISO規
格でなくしてしまったのもIBM。

我々が今日使っているPCは昔は「IBM PC/AT互換機」なぞと呼ばれたものですが、その頃の歴史
も掘り返すと、また何かロクでもないことをしているかもしれないという気がしてきました。

# re: 数字<英字 とは限りません。 2010/06/25 9:51 はつね

> 何と言いますか、「またIBMか」という感じが。

E-BCD-ICですからねー。
BCDで数字を表わしやすい(ゾーン10進としても使いやすい)コード系にして処理能力を少しで
も向上させようとした結果みたいなものですから、一概に「またIBMか」ということもできない
かと。

# re: 数字<英字 とは限りません。 2010/06/25 10:33 aetos

文字コードには内部コードと外部コードがあるって教わったですよ(今思い出した)。
内部コードってのはマシン内部で使うコード。外部コードってのは他のマシンとのデータ交換に使うコード。
だから内部コードは処理の効率化のためにどんなコードを使ってもいいけれど、外に出すときに
は他人のことを考えて外部コードにしましょうね、って。

じゃあ EBCDIC は内部コードなのかというと…E-BCD-Interchange Code ですからね、外部なんじゃないかと。
ってことは…やっぱり「またIBMか」ですかね。
# Code Page 437 2010/06/25 11:10 安岡孝一

しかもIBM PCはEBCDICじゃなくて、これまた独自文字コード(現在のCode Page 437)ですからね。
でもまあ、1980年代までは各社とも囲い込みに必死で、他社と違うものを出すのが当たり前だっ
たのかもしれません。

# re: 数字<英字 とは限りません。 2010/06/25 20:24 Ognac

根源的には、二進化十進数を拡張して文字コードにしたことが、強引だったと思うのです。
拡張するときも、アルファベットを続きコードにしなかったのは、10個刻みを意識したのかも知れません。
一企業ないのローカルルールの感覚だったのでしょうね。
業界インフラを作るという意識はまだ芽生えなかったのね。
Cobol/Fortranなどの言語も結果としてインフラ化しましたが、最初から公共性を考えたかどうか。
初期のPC/Basicや MS-DOSは各社仕様版があったし、
普及して、 デファクトスタンダードになってから、公共性を考えるのかしら。 

まあ EBCDIC というコード体系が○○だというのは否定しないし、 公共性よりも自社の利益を優先というのもまあそうなんだろうけれども。

英語版うぃきぺの EBCDIC の項から。


Extended Binary Coded Decimal Interchange Code - Wikipedia, the free encyclopedia

Extended Binary Coded Decimal Interchange Code

Extended Binary Coded Decimal Interchange Code (EBCDIC) is an 8-bit character encoding 
(code page) used on IBM mainframe operating systems such as z/OS, OS/390, VM and VSE, 
as well as IBM midrange computer operating systems such as OS/400 and i5/OS (see also 
Binary Coded Decimal). It is also employed on various non-IBM platforms such as 
Fujitsu-Siemens' BS2000/OSD, HP MPE/iX, and Unisys MCP. EBCDIC descended from the code 
used with punched cards and the corresponding six bit binary-coded decimal code used 
with most of IBM's computer peripherals of the late 1950s and early 1960s.

Contents

    * 1 History
    * 2 Codepage layout
    * 3 Criticism and humor
    * 4 See also
    * 5 References
    * 6 External links

History

EBCDIC (pronounced /ˈɛbsɨdɪk/) was devised in 1963 and 1964 by IBM and was announced 
with the release of the IBM System/360 line of mainframe computers. It is an 8-bit 
character encoding, in contrast to, and developed separately from, the 7-bit ASCII 
encoding scheme. It was created to extend the Binary-Coded Decimal (BCD) encoding that 
existed at the time, which itself was devised as an efficient means of encoding the 
two zone and number punches on punched cards into 6 bits.

While IBM was a chief proponent of the ASCII standardization committee, they did not 
have time to prepare ASCII peripherals (such as card punch machines) to ship with its 
System/360 computers, so the company settled on EBCDIC at the time. The System/360 
became wildly successful, and thus so did EBCDIC.

All IBM mainframe peripherals and operating systems (except Linux on zSeries or 
iSeries) use EBCDIC as their inherent encoding,[1] but software can translate to and 
from other encodings. Many hardware peripherals provide translation as well and modern 
mainframes (such as IBM zSeries) include processor instructions, at the hardware level, 
to accelerate translation between character sets.

EBCDIC has no modern technical advantage over ASCII-based code pages such as the 
ISO-8859 series or Unicode. There are some technical niceties in each, e.g., ASCII and 
EBCDIC both have one bit which indicates upper or lower case. But there are some 
aspects of EBCDIC which make it much less pleasant to work with than ASCII (such as a 
non-contiguous alphabet). As with single-byte extended ASCII codepages, most EBCDIC 
codepages only allow up to 2 languages (English and one other language) to be used in 
a database or text file.

Where true support for multilingual text is desired, a system supporting far more 
characters is needed. Generally this is done with some form of Unicode support. There 
is an EBCDIC Unicode Transformation Format called UTF-EBCDIC proposed by the Unicode 
consortium, but it is not intended to be used in open interchange environments and, 
even on EBCDIC-based systems, it is almost never used. IBM mainframes support UTF-16, 
but they do not support UTF-EBCDIC natively.

Arabic EBCDIC versions are typically in presentation order, in left to right order as 
displayed by an older mainframe or line printer, rather than in the right to left 
logical order used by modern encodings such as Unicode.

Codepage layout

(表部分略)

Criticism and humor

Open-source-software advocate and hacker Eric S. Raymond writes in his Jargon File 
that EBCDIC was almost universally loathed by early hackers and programmers because of 
its multitude of different versions, none of which resembled the other versions, and 
that IBM produced it in direct competition with the already-established ASCII.


(略)

後知恵レベルなら何とでもいえても、「その時点で」「ASCII」に切り替えるなんてのは 無理ぽな気がするけどねえ。

EBCDIC descended from the code used with punched cards and the corresponding six bit binary-coded decimal code used with most of IBM's computer peripherals of the late 1950s and early 1960s. (EBCDIC はパンチカードで使われていたコードから受け継がれたもので、1950 年代終盤から 1960 年代初めに使われていた IBM のコンピューター周辺機器の大半で使われていた 6ビット二進化十進コードに対応します)

It was created to extend the Binary-Coded Decimal (BCD) encoding that existed at the time, which itself was devised as an efficient means of encoding the two zone and number punches on punched cards into 6 bits. (EBCDIC はその当時存在していた二進化十進 (BCD) エンコーディングを拡張するために 作られたもので、それ自身も二つのゾーンと数値をパンチカード上に 6ビット幅で効率よくエンコーディングできました) #ちょっと自信ない

While IBM was a chief proponent of the ASCII standardization committee, they did not have time to prepare ASCII peripherals (such as card punch machines) to ship with its System/360 computers, so the company settled on EBCDIC at the time. The System/360 became wildly successful, and thus so did EBCDIC. (IBM はASCII標準委員会の chief proponent であったものの、 彼らには ASCII に対応した (カードパンチマシンのような) 周辺機器を System/360 コンピューターの出荷に合わせて揃えるだけの時間がありませんでした。 このため、IBM はその時点で EBCDIC を選択したのです。 この System/360 は大きな成功を収めましたが、それは EBCDIC を選択したからです この System/360は大きな成功を収め、それに伴って当然 EBCDIC も大きく成功しました。) って最後の一文が一番怪しい ○| ̄|_

で、日本語版はというと。


EBCDIC - Wikipedia
EBCDIC

EBCDIC (Extended Binary Coded Decimal Interchange Code) はIBMにより定義された文字コー
ドである。ゾーン形式2進化10進数をベースにした二進化十進数(BCD、Binary-coded decimal)を
拡張する形で作られたものである。読み方は「エビシディック」であり、この読み方は日本だけ
でなく、英語圏でも同様である。日本では「エビスディック」と読まれる事も多い。

7ビットで全文字を表現できない欠点があるため、GR表現を使ってJIS漢字と混在して表現出来な
い。ゆえにASCIIと比べると非常に扱いにくい1バイトコードである。

現在でも各コンピュータベンダのメインフレーム及びオフコンにおいて使用されている。

文字コードの配置
(表は略)

本来は上に示した表内の58文字のみが規定されているが、各社それぞれの拡張を行い、英小文字・
半角カナ・一部記号を未定義の位置に追加していることがある。ただし、この場合は英小文字と
半角カナを同時に利用できない。

また、これとは別に日立製作所が英小文字と半角カナ文字を同時に利用出来るように拡張をした
コードをEBCDIKと言うが、この他にもたくさんのベンダ毎の(英小文字と半角カナ文字が同時に
利用できる)拡張コードが存在する。

    * カナ拡張されたEBCDICコードの例(IBMによるカナ拡張の一例;コードページ:298の場合)

(略)

ひらがなや漢字などが扱えるよう、さらなるコード拡張を独自に行なっている例もある。

が、EBCDICのコード拡張には、JIS漢字のような日本語を扱う為の標準規格が存在しない為に、
アーキテクチャの異なるコンピュータ間での文字データのやり取りに、支障をきたす場合がある。

特に、JIS漢字に基づいて動作しているコンピュータとの記録媒体を介したやり取りや、インタ
ーネット越しの通信を行なう場合は、適切な文字コード変換ができないのが原因で文字化けなど
の問題に繋がりやすい。

制御文字コードの配置

EBCDICにおいてもASCIIと同様、通信処理の制御や周辺機器の制御などの目的に用いる文字コー
ドが存在する。割り当て範囲は、16進数表現の00hから3Fhの間と0FFh。

    * IBMによるカナ拡張の一例(コードページ:298)と組み合わせた場合のコード表

(略)

ASCIIと共通の機能名称を持つ制御文字コードがある反面、プリンタ等の基本的な改行制御に関
わる制御文字コードの個数に差異があるといった違いもある。

EBCDIC:CR=Carriage Return、NL=New Line、LF=Line Feed、FF=Form Feed(計4種類)
ASCII:CR=Carriage Return、LF=Line Feed、FF=Form Feed(計3種類)

外部リンク

    * IBM Code Pages IBM社による各コードページの説明(英語、PDF形式)
    * IBM CDRA Reference Appendix A. Encoding Schemes(IBMのコード化体系の説明、英語)
    * IBM/System i Globalization/IBM Control Codes/Control character Mappings (IBM社による制御文字コードの説明文、英語)

うぉーい。英語版の肝心なところが全然ないじゃん ○| ̄|_

おまけ。 ASCII - Wikipedia, the free encyclopedia

そういやあイギリスとかで開発されていたコンピューターではどうだったんだろう? あの本に載ってたりするだろうか。

■_ 本日の巡回から

2010年06月24日

■_

日経ソフトウエアの発売日だったの忘れてた…

MIPS ってレジスター→レジスターの転送命令なかったのか… (ゼロレジスターとビット演算でごにょごにょする)

■_

Journal of chromatic (983)

Perl 6 Design Minutes for 26 May 2010
[ #40408 ]

The Perl 6 design team met by phone on 26 May 2010. Larry, Allison, Patrick, Will, and 
chromatic attended.

Larry:

    * :() syntax is now always signature
    * we now use foofix:[...] as the general op form instead of foofix:(...)
    * refactored the sematics of :nth and :x
    * :nth() now only ever takes a monotonically increasing list
    * S03 now explains how "not-raising" works on != and ne
    * it now basically matches the intuitions of an English speaker via HOP definition of
      negate metaop
    * STD sometimes didn't require semi between statements
    * statement modifiers are expression terminators but not valid statement terminators
    * an unexpected statement modifier word like if could terminate one statement and
      start another
    * fixed up backslashes in character classes to allow \s etc and reject \u etc
    * STD was accidentally using the same lexpad for different multis
    * Cursor now treats :() on name extension as a signature always, never as a categorical
    * we shouldn't introduce the stopper for circumfix until we're in the circumfix, or we
      can't use the same char on both ends
    * placeholder messages error messages are now much more informative and correct
    * we now disallow use of placeholder after same variable has been used as a non-placeholder,
      even for an outer reference
    * renamed add_macro (which it doesn't) to add_categorical (which it does)
    * participating frequently in discussions on semantics both on irc and p6l
    * working closely with sorear++ as he brings viv closer to bootstrapping, yay!
    * soon can bootstrap past gimme5

以下略

なんかこう…

■_ 本日の巡回から

■_

軍オタが好きな名言、名ゼリフ 6 
797 名無し三等兵 [age] 2010/06/24(木) 23:59:53 ID:??? Be:
    活動的な馬鹿より恐ろしいものはない

                                       ゲーテ 

ハマーシュタイン(ゼークトの言葉として知られているみたいですが)のアレに通じますね。

■_ Scala vs. F#

後半。

Scala vs. F#: Comparing Functional Programming Features — Developer.com

F# vs. Scala: List Comprehensions (リスト内包)

**
list comprehensions →リスト内包表記

というのが主流と思いますが、どうも「表記」が尻尾につくのが気になるので
ここでは「リスト内包」とします。内包表記がお好みの方は、ご自分で補完して
お読みください。
Originally popularized by Haskell (another, archetypical functional language), list comprehensions are in mathematical terms set-builder, notation-based expressions for the definition of lists. For example, in Haskell one would use the following list comprehension to produce a list of nums containing only squares of numbers greater than 2: 元々リスト内包は Haskell (もうひとつの、archetypical な関数型言語) によって広まったも のであり、数学用語 (mathematical terms) の set-builderで、リストの定義のための notation ベースの式です。 #よくわかんねー たとえば Haskell では、2 よりも大きな数の平方だけからなる nums のリストを生成するため には次のようなリスト内包を使うことでしょう: def squares = [ x*x | x <- nums, x > 2 ] The F# equivalent for list comprehension is called a generator comprehension, and it can be used for both lists and sequences. In functional languages, sequences are similar to lists except that elements in the sequences (e.g., 1…1000) are calculated only when requested, making them more storage efficient. F# でリスト内包に等価なものは generator comprehension と呼ばれていて、リストとシーケン スの両方に対して使えます。関数型言語においてシーケンスはリストと同じものですが、シーケ ンスではストレージをより効果的に使うためにその要素は要求されたときにだけ計算される点が 異なります List generators have the following form: リストジェネレーターは次のような形式です: [for x in collection do ... yield expr] Sequence (seq) generators have this form: シーケンスジェネレーター (seq) は次のような形式です: seq {for x in collection do ... yield expr} So, the F# version of the previously shown Haskell list-generation example for multiples of values over 2 has the following syntax: ですから、先に見た 2を超える値の掛け算を行っていた Haskell 版リスト生成の例は F#版では次のような構文になります: del list = [for x in 0..100 if x > 2 do yield x*x] In Scala, list comprehension has the following structure: Scala ではリスト内包は次のような構造です: val type = for ( range ) [if (condition)] ) yield result Here is a Scala version for multiple list comprehension: そして Scala での掛け算を行うリスト内包の例です: val list = for (i <- 1 to 100; if (i > 2)) yield i*i F# vs. Scala: Multiple Inheritance via Mixins (Mixin を使った多重継承) One notable difference between F# and Scala is the lack of support for multiple inheritance in F#. In Scala, programmers can declare that a child extends from one primary class, but that it can also inherit "traits" from other classes. F# と Scala との違いで顕著 (notable) なものの一つが、F# には多重継承 (multiple inheritance) のサポートが欠如していることです。Scala ではプログラマーはひとつの primary クラスから extends した子供を宣言できるだけでなく、ほかのクラス群から “traits”を継承できます。 In so-called mixin class composition, subclasses inherit through mixin the delta of a class definition (i.e., a class will inherit all new definitions that are not inherited through direct inheritance). In the example below, OtherParentClass is used as a mixin. mixin と呼ばれる class composition (クラス合成) において、サブクラスは delta of a class definition (クラス定義の差分?) の mixin を通じて継承しています (あるクラスは direct inheritance を通じて継承されていないすべての新しい定義を継承します)。次の例では OtherParentClass に mixin が使われています。 Class MixinSubclass extends BaseClass with OtherParentClass Base classes are declared with the keyword extends and mixins (zero or many) are declared with keyword with. ベースクラスは extends というキーワードとともに宣言され、mixin は with というキーワー ドと共に宣言されます(mixin の部分はなくても複数でもかまいません)。 Inherited methods are explicitly overridden with the keyword override to prevent accidental overriding: 継承されたメソッドは間違ってオーバーライドするのを防ぐために、予約語 override を使ってオーバーライドすることを明らかにします。 override def calculate(dx: Int, dy: Int): Distance = new Distance(x + dy, y + dy ) OtherParentClass would be declared with keyword trait: OtherParentClass は予約語 trait を使って宣言されます: trait OtherParentClass def count:Int def kmDistance = count * 1.66 Summary まとめ For the most part -- except for Scala mixins -- F# and Scala offer similar expressive power when it comes to functional programming. They both are flexible, powerful programming languages with strong functional features. In this article, I presented an abbreviated comparative review of the most essential functional programming features of these two languages. F# と Scala は、関数プログラミングということになれば Scala の mixin を除くほとんどの部 分で similar expressive power を offer しています。両方ともが flexible であり、 strong な関数的機能 (functional features)を備えた powerful なプログラミング言語です。 # strong と powerful をどう日本語にしたものか この article でわたしは、これら二つの言語の関数プログラミング機能の最も essential な部 分についての abbreviated (要約、抄訳) された comparative review を行いました。 Why abbreviated? Because functional programming is perhaps the most flexible type of programming, offering a number of small features and subtleties that would make a detailed comparison of all features very lengthy -- far beyond the scope of a single article. Why abbreviated? なぜ要約なのでしょうか? Because functional programming is perhaps the most flexible type of programming, それは関数プログラミングはおそらくプログラミングのタイプのなかで最もフレキシブルなものなので、 offering a number of small features and subtleties that would make a detailed comparison of all features very lengthy -- far beyond the scope of a single article. In the next installment, I will compare and contrast the features where these two languages most differ: application development models and runtime characteristics. For Further Reading # The Scala Programming Language homepage # The Microsoft F# Developer Center About the Author Edmon Begoli is a software architect with 14 years of professional experience on large commercial and public software projects. He is a member of the R&D staff at Oak Ridge National Laboratory.
Related Articles
関連する articles 

    * Getting Functional with F#
    * Using Functional Construction to Create XML Documents
    * Clojure: Immutability at the Language Level

2010年06月23日

■_

・今日は
タイタニア(5) (シリウスコミックス) あそびにいくヨ! 7 (MFコミックス アライブシリーズ)
これだけ。

■_ Scala vs. F#

Scala vs. F#: Comparing Functional Programming Features — Developer.com

Scala vs. F#: Comparing Functional Programming Features (関数言語機能を比較する)


F# and Scala, two relatively recent programming languages, provide most .NET and Java 
software developers with new functional programming features that are worth 
understanding and evaluating. (Read a Short Briefing on Functional Programming for a 
primer on how functional programming works.)

F# と Scala は比較的最近のふたつのプログラミング言語で、.NET および Javaのソフトウェア
開発者に、理解し評価する価値のある新しい関数プログラミングの機能を提供するものです
(Read a Short Briefing on Functional Programming for a primer on how functional programming works.)


Scala is a Java-based, general-purpose language that is intended to appeal to both 
adherents of functional programming as well as devotees of more mainstream imperative 
and object-oriented programming. It compiles into Java bytecode and runs on top of the 
Java Virtual Machine (JVM).

Scala は Java をベースとした汎用目的 (general-purpose) 言語で、よりメインストリームに
ある命令型プログラミングやオブジェクト指向プログラミングの devitees (熱狂的なファン) 
だけでなく関数プログラミングの adherents (支持者たち) にも同じようにアピールしようとも
くろんだものです。Scala はソースコードをJavaのバイトコードに変換し、それを Java 
Virtual Machine (JVM) の上で実行します。


While Scala is fundamentally a functional language, it also embodies all the elements 
of imperative and object-oriented languages, which gives it the promise of introducing 
functional programming features to a broader programming community.


Scala は fundamentally には関数型言語なのですが命令型言語やオブジェクト指向言語のすべ
ての要素も統合していて、より広範なプログラミングコミュニティに対して関数プログラミング
の機能を intorduce することを目指しています。


F# is a general-purpose programming language developed by Microsoft to run as part of 
.NET's Common Language Runtime (CLR). It is based on another, orthodox functional 
language, Ocaml. Microsoft introduced F# into the .NET platform because of, among 
other reasons, the increased interest in functional programming and functional 
programming's suitability to high-performance computing and parallelism.

F# はMicrosoftによって開発された.NET's Common Language Runtime (CLR) の一部として実行
するようになっている汎用目的のプログラミング言語です。F# はもう一つ orthodox 
functional language である Ocamlに基づいています。Microsoft が F#を .NET プラットフォ
ームに持ち込んだのは、関数プログラミングそのものや関数プログラミングのhigh-performance 
computing や parallelism に対する適性 (suitability)への関心が高まってきているからです。

Although its syntax is distinctly functional, F# actually is a hybrid 
functional/imperative/object-oriented language. Its object-oriented and imperative 
features are present mostly for compatibility with the .NET platform, but F#'s 
tripartite nature is also pragmatic -- it allows programmers who use any or all of the 
three programming paradigms to program exclusively in one or to combine all three.

F# の構文は distinctly に関数的でありますが、実際には関数型言語、命令型言語、オブジェ
クト指向言語のハイブリッドです。F# のオブジェクト指向的機能や命令型の機能はおおむね 
.NET プラットフォームの互換性に対して提供されていますが、F# の tripartite nature もま
た実践的 (pragmatic) です -- 先の三つのプログラミングパラダイムのいずれかもしくはすべ
てを使うプログラマーが exclusively in one or to combine all threeにプログラムすること
を許しています。


In this article, I will compare and contrast the functional features and related 
syntax of F# and Scala.

この article でわたしは、 F# と Scala の関数的機能とそれに関連した構文の比較及び
contrast を行います。


F# vs. Scala: First Order Functions

Functions in F# and Scala are treated as first order types. They can be passed in as 
arguments, returned from other functions, or assigned to a variable.

F# や Scala における関数は first order types として扱われます。これは引数として渡した
り、別の関数から返されたり変数に代入するといったことが可能です。

In this F# code snippet, I first define a function (increment) that adds 1 to a passed 
value, and then I define the function doubler, which takes type myfunc and applies 2 
to it as a parameter. Finally, I invoke the function handler with a parameter 
incremented to it. The function incrementis passed as a regular value, hence the 
function is being treated as a first order type:

この F# のコード片では、最初に渡された値に対して1を加える 関数 increment を定義してい
ます。次に myfunc 型を受け取ってそのパラメータとして 2 を適用する関数 doubler を定義し
ています。最後に、インクリメントするためのパラメーターつきで関数ハンドラーを起動してい
ます。関数は first order typeとして扱われるので、この関数は渡されたものを通常の値 
(regular value) としてインクリメントします

let increment x = x + 1
let handler myfunc = (myfunc 2)   
printfn "%A" (handler increment)


Notice the type inference in the example above. F# will infer that x is an integer 
because I add 1 to it, and so x will be treated as an integer (Int) type.

先の例にあった type inference に注目してください。F# は 1 を x に加えており、また
x は整数型 Int として扱われるであろうことからx が整数であると infer します。


Here is the same example in Scala:

Scala で同じ例を書いてみます:


def increment(x:Int) = x + 1
def handler( f:Int => Int) = f(2)
println( handler( increment ))



F# vs. Scala: Lazy Evaluation (遅延評価)

F# supports lazy evaluation, but for performance reasons it is not enabled by default. 
Instead, F# supports so-called eager evaluation: functions can be marked for lazy 
evaluation by explicitly labeling them with the keyword lazy and running the program 
with the Lazy.force option specified.

F# は遅延評価をサポートしていますが、性能上の理由からデフォルトでは有効になっていません。
代わりに F# では、eager evaluationと呼ばれるものをサポートしています:
予約語 lazy を使って関数にラベル付けを明確な形で行うことで遅延評価のための関数に対する
マーク付けが可能で、さらに実行時にプログラムに Lazy.force オプションを指定します。

#eager evaluation → 遅延評価の逆。できるときにがんがん評価しちゃう
#ちょー大雑把な説明なので、良い子は自分で調べてね♪

let lazyMultiply = lazy ( let multiply = 4 * 4  )


Like F#, Scala is not lazy by default, but unlike F#, values -- not functions --have 
to be marked with the keyword lazy and therefore evaluated as call-by-need.

F# と同様に、Scala はデフォルトでは lazy ではありません。しかし F#と異なり関数ではなく
値で、lazy というキーワードでマークされたものが call-by-need で評価されます。

def lazyMultiply(x: => y:) = { lazy val y = x * x }



F# vs. Scala: Lambda Expressions and Currying (λ式とカリー化)

Currying is an essential feature of functional programming that allows for the partial 
application of functions and functional composition. F# supports currying. Here is an 
example of the curried function add in F#:

カリー化は関数の部分適用や関数合成を可能にしている、関数プログラミングの essential な
機能です。F# はカリー化をサポートしています。以下のコードは F# でのカリー化された関数
add の例です。


Declaration:
宣言:

val add : int -> int -> int



Implementation:
実装:

let add = (fun x -> (fun y -> x + y) )



In Scala, the curried function add looks like this:
Scala では、カリー化された関数 add は次のようになります:

def add(x:Int) = (y:Int) => x + y



F# vs. Scala: Lambda Expressions (λ式)

F# also supports Lambda expressions (anonymous functions). In F#, lambda expressions 
are declared with the keyword fun. In the example below (adopted from F# documentation), 
an anonymous function is applied to a list of numbers to increment each number in the 
list and return a new, incremented list:


F# も λ式 (無名関数 anonymous functions) をサポートしています。F# では、λ式は fun とい
う予約語を使って宣言されます。次の例 (F# のドキュメントから転載) では無名関数は数値の
リストに対して適用されていて、リスト中の個々の数値をインクリメントして新しいインクリメ
ント済みのリストを返しています。


let list = List.map (fun i -> i + 1) [1;2;3] 
printfn "%A" list



Lambda expressions in Scala are defined in a very succinct fashion. This is how you 
would increment a function with a Lambda expression (x=>x+1) on a list of numbers 
(1,2,3) in Scala:

Scala における λ式は非常に簡潔な fassion で定義されています。次の Scala コード片は 
x=> X+1 という λ式 を使った関数が数値リスト (1,2,3) に対してどのようにインクリメン
トするかの例です。


val list = List(1,2,3).map( x => x + 1 ) 
println( list )



F# vs. Scala: Pattern Matching (パターンマッチング)

Pattern matching is a powerful feature of functional programming languages that allows 
blocks of code within the function to be 'activated' depending on the type of a value 
or an expression. (Think of pattern matching as a more powerful variation of the case 
statement.)

パターンマッチング (pattern matching) は、関数の中にある値や式の型に応じて“activated”
するコードのブロックを置くことを可能にする関数型プログラミング言語の強力な機能です
(パターンマッチングは case 文のさらに強力なバリエーションであるように考えてください)。


In F# , the vertical line character (|) is used to denote a case selector for the 
function match specification. Here is an F# version of a pattern-matched Fibonacci 
number function:

F#では、バーティカルバー (|) は
関数の match specification のための case セレクターを表すのに使われています。
次のコードは F# 版のパターンマッチを使ったフィボナッチ数関数 (Fibonacci number function)
です。


let rec fib n =
     match n with
     | 0 -> 0
     | 1 -> 1
     | 2 -> 1
     | n -> fib (n - 2) + fib (n - 1)



Like F#, Scala supports pattern matching on functions. Here is the example of a 
Fibonacci number calculation in Scala. Notice that Scala uses the keyword case:

F#に似て、Scala は
関数におけるパターンマッチングをサポートしています。
以下のコード片は Scala でフィボナッチ数を計算する例です。

def fib( n: Int): Int = n match {

    case 0 => 0
    case 1 => 1
    case _ => fib( n -1) + fib( n-2)
  }


この続きもあるけど改めて。

■_ なんだろう


推薦図書/必読書のためのスレッド 56 
681 デフォルトの名無しさん [sage] 2010/06/21(月) 02:33:56 ID: Be:
    Cの基本的な文法の本じゃなくて何か作ったりとかの楽しい本探してます。エスパーの方お願いします。 

718 デフォルトの名無しさん [sage] 2010/06/22(火) 19:15:44 ID: Be:
    >>681
    http://www.amazon.co.jp/dp/4871482006/
    http://www.amazon.co.jp/dp/4774100544/
    おもいっきり硬派な線で。 

719 デフォルトの名無しさん [sage] 2010/06/22(火) 20:16:29 ID: Be:
    >>718
    LISP処理系の作成の古書価格ひでぇw 

723 デフォルトの名無しさん [sage] 2010/06/22(火) 20:46:00 ID: Be:
    >>719
    lisp の処理系を書籍にしたのは、この二つくらいでしょうからね。 

724 デフォルトの名無しさん [sage] 2010/06/22(火) 21:05:29 ID: Be:
    >>723
    30年くらい前の話だけど
    Fortranで作るLisp処理系の雑誌連載があったよw 

725 デフォルトの名無しさん [sage] 2010/06/22(火) 22:01:18 ID: Be:
    Fortran Iだったら凄い 

726 デフォルトの名無しさん [sage] 2010/06/22(火) 22:05:14 ID: Be:
    もともとFortranで動いてたんでしょ 

727 デフォルトの名無しさん [sage] 2010/06/22(火) 22:13:16 ID: Be:
    lisp処理系とかまあ大した物ではないけど
    再帰のない昔のFORTRANで作るのは少し工夫が必要そうだな
    まあスタックを自前で用意すればいいだけだが 

728 デフォルトの名無しさん [sage] 2010/06/22(火) 23:10:15 ID: Be:
    >>725
    Fortran77だったような
    MU-LISPって名前だったと思うんだけど、ググったら同名のがゾロゾロ出てビビった
    同じものかどうかは分からんが必読書でないことは確かだw

    あ、ドラゴンブックって第二版が出てたのね
    今更インタプリタやコンパイラ自分で作ることも少ないだろな…買うのを躊躇するね 

729 デフォルトの名無しさん [sage] 2010/06/22(火) 23:14:56 ID: Be:
    独自のスクリプト作る仕事ならこの前やったし
    あるとこにはあると思うよそういう仕事 

731 デフォルトの名無しさん [sage] 2010/06/23(水) 09:08:13 ID: Be:
    >>724
    Bit に後藤先生が連載した奴? 

732 デフォルトの名無しさん [sage] 2010/06/23(水) 13:40:59 ID: Be:
    >>731
    Informationだったかな?A4版、濃い青の表紙の月刊誌 

733 デフォルトの名無しさん [sage] 2010/06/23(水) 13:55:21 ID: Be:
    インターフェースかな、と思ったんだけど、1995年までの装丁は黒地に黄色字なので違うね。
    洋書? 

734 デフォルトの名無しさん [sage] 2010/06/23(水) 14:28:54 ID: Be:
    30年前かーーーーー 

735 デフォルトの名無しさん [sage] 2010/06/23(水) 14:41:10 ID: Be:
    >>733
    日本語の月刊誌だった
    厚さは大したことなかった 

736 デフォルトの名無しさん [sage] 2010/06/23(水) 15:15:17 ID: Be:
    これかなぁ?
    ttp://webcat.nii.ac.jp/cgi-bin/shsproc?id=AN0002803X 

741 デフォルトの名無しさん [sage] 2010/06/23(水) 22:32:59  ID: Be:
    >>736
    それかもね
    あえて繰り返すが、必読書でないことは確かだw

30年前とかで、A4サイズの雑誌ってそんなになかったような気がするんだよなあ。 って、Oh! なんちゃらはA4か? 736 の挙げてるのはわからんw

■_ 本日の巡回から

2010年06月22日

■_

・再開
The History of Python: New-style Classes The History of Python: import this and The Zen of Python The History of Python: import antigravity 訳している人がいるので待つかな。

・生誕百年
Konrad Zuse ノイマンやチューリング辺りに比べると知名度が低い気がするけどどうだろうか。 まあプランカルキュール(言語表記調べるのめんどいw)経由で知っている人もいるか。 まつもとさんが連載に書いたこともあったし。

・気がついたら
おかしい。池袋まで足を伸ばす気はなかったはずなのに気がついたらなぜか手元に
今日の獲物
書評とかは他の人に任せたっ!

ボクらのScala ~ 次世代Java徹底入門 関数プログラミングの楽しみ

■_

まあ知らない人が見たらびっくりするだろうなあ。これは。


Strange ruby syntax - Stack Overflow

Hi, what the syntax is in Action Mailer Basics rails guide ?

class UserMailer < ActionMailer::Base
   def welcome_email(user)
      recipients    user.email
      from          "My Awesome Site Notifications <notifications@example.com>"
      subject       "Welcome to My Awesome Site"
      sent_on       Time.now
      body          {:user => user, :url => "http://example.com/login"}
   end
end

How should i understand the construction, like

from "Some text for this field"

Is it an assignment the value to a variable, called "from" ?

これは from という名前の変数への値の代入なのでしょうか?

It is a call to a method from with the argument "Some text for this field"

これは、 "Some text for this field"を引数としたメソッド呼び出しです。

The method comes from the ActionMailer::Base class that your UserMailer extends from.

In Ruby the parentheses around a method call are optional unless something would be
ambiguous so the statement is equivalent to from("Some text for this field")

Ruby ではメソッド呼び出しの際のカッコは、解釈にあいまいな点が出ない限り
省略が可能です。問題の文は  from("Some text for this field") と
同じことです。

Rails has a coding style that prefers to be close to natural language where possible,
hence not using parentheses unless necessary.

Calling this method sets an instance variable @from to the value you provide so that
it can be used later when sending the message.

Normally when you have accessor methods for getting and setting a variable you would
have from= to set the value and from to return the value, however ActionMailer uses
something called adv_attr_accessor to define the from method so that if you call it
with a parameter then it acts as a setter but if you call it with no parameters then
it acts as a getter.

This can be seen in actionmailer-2.x.x/lib/action_mailer/base.rb and
actionmailer-2.x.x/lib/action_mailer/adv_attr_accessor.rb

It's not an assignment. In Ruby, assignments are done using the assignment operator =
like this:

var = val

You are probably thinking of some Lisp dialects where assignment looks like this:

(def var val)

It's just a simple receiverless message send.

In Ruby, the general syntax for a message send is

receiver.selector(argument1, argument2)

However, if the receiver is self, you can leave off the receiver, so

selector(argument1, argument2)

is the same as

self.selector(argument1, argument2)

[Note: this is not quite true. In Ruby, private methods can only be invoked via a
receiverless message send, so if in this example self responds to the selector message
by invoking a private method, only the first variant will work, the second will raise
a NoMethodError exception.]

Also, in cases where there are no ambiguities, you can leave off the parentheses
around the arguments like this:

receiver.selector argument1, argument2

If you put the two things together, you can now see that

selector argument1, argument2

is equivalent to

self.selector(argument1, argument2)

and thus

from "Some text for this field"

is equivalent to

self.from("Some text for this field")

There is a third shortcut in Ruby's message sending syntax: if the very last argument
to a message send is a Hash literal, then you can leave out the curly braces. So, the
last line in the above example could also be written as

  body          :user => user, :url => "http://example.com/login"

Also, in Ruby 1.9, a Hash literal where all keys are Symbols can be written using an
alternative Hash literal syntax:

 { key1: val1, key2: val2 }

is the same as the old syntax

{ :key1 => val1, :key2 => val2 }

which means that, at least in Ruby 1.9, that last line could also be written as

  body          user: user, url: "http://example.com/login"

■_ 本日の巡回から

■_ 注文!=取り寄せ

んー。どうなんだろうねい。

書店員の情報交換スレ44 
481 マロン名無しさん [] 2010/06/22(火) 01:32:32 ID:eLsHqjXU Be:
    「ガンガンの注文お願いします」
    「ごめんなさい、もうメーカーにも在庫がないんですよ」
    「そうですか。わかりました。では取り寄せでお願いします」 

482 マロン名無しさん [sage] 2010/06/22(火) 02:06:40 ID:??? Be:
    >>481
    話聞いてないwww 

483 マロン名無しさん [sage] 2010/06/22(火) 05:57:25 ID:??? Be:
    >>481
    吹いたwww 

484 マロン名無しさん [sage] 2010/06/22(火) 12:53:03 ID:??? Be:
    >>482
    いや、意味が分かってないんだよ。
    取り寄せと注文が違うもんだと思ってんだよ。

    馬鹿だからしょうがない。 

485 マロン名無しさん [sage] 2010/06/22(火) 14:39:27 ID:??? Be:
    >>481
    中学生くらいまでならちゃんと教えてやってw 

486 マロン名無しさん [sage] 2010/06/22(火) 17:58:50 ID:??? Be:
    ハガレンじゃない漫画目当てのお客さんからの問い合わせが凄い。
    付録無しでいいからなんとか再販できなかったのかな。 

487 マロン名無しさん [sage] 2010/06/22(火) 19:49:27 ID:??? Be:
    ガンガンについてのお問い合わせはこちらまで
    でスクエニの代表の番号はりだしてる
    いちいち相手にしてらんない 

488 マロン名無しさん [sage] 2010/06/22(火) 23:35:27 ID:??? Be:
    >>481
    ……注文と取り寄せの位置が逆なだけで、昨日の俺のやりとりと全くだ。
    ちなみにそのお客さんは、注文すれば1冊だけ作ってもらえるものだと思っていたよ……。 

ほかの作品読みたかった(いつも買っている)人は災難だなあ。

2010年06月21日

■_

センゴク外伝の今川義元は、 これまであまたある作品で一番かっこよく描かれているんじゃなかろうか。 大抵は桶狭間でのやられ役でしかないものねえ。

■_

■_ 比較

Python vs. Perl

Comparing Perl and Python

Comparing Perl and Python

Published on 2010.06.17 at 13:16:46 Bookmark and Share


Standing at a Perl booth at technical events gives you a lot of opportunities to talk 
to nice people. They often ask how does Perl and Python compare. I try to be diplomatic,
even if that does not always work. Here is what I tend to answer:


Size and complexity (大きさと複雑さ)

Perl, the language is much larger than Python so probably it takes longer time to 
learn Perl than Python but in the end you have a more expressive language.

Perl は Python よりも格段に大きな  (much larger than) 言語 であるので、Perl を学ぶには
おそらく Pyton よりも長い時間を必要とします。しかし、最終的にはより expressive な言語
を得るでしょう。


The standard libraries of Python cover a lot more fields than those of Perl as Python 
has an approach of batteries included while Perl is now following a "small core"
approach. This makes it easier to distribute simple applications written in Python as 
they have a better chance of not needing any external dependencies except a specific 
version of Python.

Python は batteries included のアプローチを採用していて、現状 "small core" 
アプローチを採用している Perl に比べると Pyton の標準ライブラリは Perl のそれよりもず
っと多くのフィールドをカバーしています。これは Python の特定のバージョンに依存するかも
しれないことを除けば外部に一切依存する必要のない better chance を有するようなPython で
書かれた単純なアプリケーションを配布するのをより簡単にします。


On the other hand CPAN is the killer feature of Perl. It has a lot more extensions 
than Python has. It has a central location with a standardized installation process 
and a standardized way of installing dependencies.

一方、CPAN は Perl の killer feature です。CPAN には Pyton が持つ拡張よりも大量の拡張
があります。また CPAN には標準化されたインストールプロセスと標準化された依存しているも
ののインストール (installing dependencies) 方法を備えた central location があります。

Lastly on the application development level it seems that you can find a lot more 
application frameworks and a lot more ready made applications written in Python than 
in Perl.

最後にアプリケーション開発のレベルでは、アプリケーションフレームワークや ready made な
アプリケーションでは Perl で書かれたものよりも Python で書かれたものを数多く目にするこ
とでしょう。

Approach and community (アプローチとコミュニティ)

That's one direction of comparing the two languages. The other one is the general 
approach to things. Python programmers have the idea of There should be one obvious 
way to solve a problem while Perl programmers tend to think in TMTODWDI - There's More 
Than One Way To Do It.

これはこの二つの言語を比較する一つの方向 (direction) です。これとは別のものの一つが、
ものごとに対する一般的なアプローチ (general approach to things) です。Python プログラ
マーは There should be one obvious way to solve a problem (ある問題を解く明らかな解法
(obvisous way) が一つあればよい) という考えをもっているのに対して、Perl プログラマー
は TMTODWDI - (There's More Than One Way To Do It やり方は一つではない) と考える傾向が
あります。

This leads to an interesting clash in the cultures. People who prefer more centralized 
governing will tend to use Python and think that it is the right way to do things. 
Seeing people use Perl makes them nerveous or even aggressive.

これは interesting clash in the cultures に繋がります。より centralized された governing
が好きな人たちは Python を使う傾向があり、Perl を使う人たちを見ることは彼らを神経質
(nerveous) にさせたり、aggressive にさえしてしまいます。


On the other hand Perl programmers will think there is more than one way to do things. 
One of them can be Python.

一方 Perl プログラマーは there is more than one way to do things と考えるでしょう。
そのうちの一つが Python かもしれません。

This can give them a much more relaxed approach.

At least I hope so.


© 2004-2010 Gabor Szabo

■_ 適応?

まあありがちなんですが。

エクセル Z→A、A→Zが適応されないのです。 | OKWave
エクセル Z→A、A→Zが適応されないのです。

エクセル Z→A、A→Zが適応されないのです。

並べ替えを行うときは、並べ替えをしたい列のセル1つをアクティブにすれば
OKだと思っていたのですが、誤りでしょうか?(同じ数字がない場合)

表内に斜線が入っている場合は並べ替えが成功しないのでしょうか?

オプションで並べ替えをする順番を選択しても成功できなかったのですが
どんな理由が考えられるのでしょうか。

どうぞ宜しくお願い致します。

「適用」ですよねえ。音だけでしか知らないのかしらん。

■_ パロディ

これは画像を見ないとわからないと思うんで、リンクたどってみてください。

po-ru.com: Ruby propaganda

Ruby propaganda


Thanks for stopping by, but please look at the date at the bottom of this post and 
read this update before you flame me. It's really old!

In order to make sense of this, you need to know that Ruby and Python are computer languages that have quite a lot in common. Although Ruby is much more popular in its native Japan, Python is better-known in the west. Ruby's popularity has been growing recently, thanks to some decent books and tutorials becoming available in English. I was inspired by this piece of Python propaganda to make one for Ruby. I found the perfect remixing material in a North Korean propaganda poster. So, with tongue in cheek, here it is: (略)

なぜか今になってコメントがいきなりついてしまったという。 んで、その元となったものとかの説明。

po-ru.com: Old jokes revisited

Old jokes revisited

It seems that I've created the Muhammad cartoon of the programming world. Oops. I never
intended it that way.

Six years ago, I was programming in Ruby. There weren't so many of us back then. I 
spent a lot of time in the #ruby-lang IRC channel learning, teaching, and chatting.

One day, someone found a humorous Python propaganda poster that someone had made by 
adding captions to an old Chinese propaganda poster; captions like:

    Don't use Perl; it's counter revolutionary

Chinese Python propaganda poster

We all found this fairly entertaining. Around this time, some North Korean propaganda 
posters had been going around the media, and one of them struck me as a perfect base 
from which to work.

North Korean propaganda poster

And this is what I came up with. It's not subtle:

    USE RUBY! CRUSH THE PYTHON!

(以下略)

画像見ないとわからないし、見てもわからない人もいるかな(^^;

■_ 本日の巡回から

■_OOo

後で全文訳…せたらいいなあ


OpenOffice at the crossroads - The H Open Source: News and Features

OpenOffice.org is a flagship for free and open source software, released under free 
software licenses and achieving downloads in the hundreds of millions. OO.o is a 
success by most measurements, but there have long been murmurings of discontent among 
developers resulting in complaints of "non-responsiveness and lack of leadership"
on the project. The argument is not that the project is a failure, but that
OpenOffice.org could be so much more, given a less top down approach to project
management and a looser rein on developers' ability to get involved. 

OpenOffice.org はフリーソフトウェアとオープンソースソフトウェアの旗艦 (flagship)
であり、フリーソフトウェアライセンスのもとでリリースされていて、数億 (handreds of
millions) に及ぶダウンロード回数があります。OO.o はほとんどの尺度 (measurements)
において成功したといえるものですが、長いことプロジェクトに対して
"non-responsiveness and lack of leadership" に関する不平が
開発者たちの中でささやかれています。ここで主張するのはプロジェクトが失敗した
ということではなくて、OpenOffice.org はトップダウンアプローチによるプロジェクト
管理から離れて、成果を得るために開発者たちの能力に対する縛りをゆるくすることが
できるのではないかということです。
#さいごちょーあやしい

■_ そいや

Kntuh センセイの重大発表って?


一つ前へ 2010年6月(中旬)
一つ後へ 2010年7月(上旬)

ホームへ


Copyright (C) 2010 KIMURA Koichi (木村浩一)
この文書の無断転載はご遠慮ください(リンクはご自由にどうぞ)。

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp