yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2017/09 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
金配りの次の一手
2009/03/16(Mon)22:33:06
 現在の自民党における屈指の実力者といえば、与謝野氏と考えて間違いないでしょう。この深刻な経済状況において、株に満期があると勘違いするレベルの人間がまっとうな策を打てるわけがありませんし、日銀といった重要な機関は建前上政府とは独立していますので、ここで指揮を取れるのは経済関連ポストをすべて占めている与謝野氏を置いて他にありません。最近はまともな人材が見当たらない状況の自民党だけに、実力者の与謝野氏が次期総裁の主要候補と目されるのも無理はありません。
 確かに、与謝野氏は実力面では問題のない人間であると見られます。麻生氏や安部氏のように実力の伴わない人間が首相のポストに就けば、日本を巻き込んで没落するのは今までの実例から明らかですし、同様の理由から実力のない舛添氏などを据えるのも論外です。選挙前にまたしても首相交代を行うのかは定かではありませんが、それを行うにしても行わないにしても、当面は与謝野氏が中心となって経済対策を進める可能性は高いといえます。
 私は与謝野氏の方針に対して全面的に賛成はしませんが、解散もいつになるか分からない現状において、経済を手当てできる人は実質的にこの人しかいませんので、ある程度の期待をしていました。何より実力者ですし、そもそも選挙管理内閣として発足した一発屋的な麻生内閣にあって、珍しく堅実に物事を遂行するタイプとみられるためです。
 しかしながら、ここで与謝野氏が困ったことを言い出しました。自民党の「政府紙幣・無利子国債発行を検討する議員連盟」なる議連が提言を提出したことを受け、無利子非課税国債と政府紙幣発行を検討するというのです。与謝野氏はもともとこの種の政策に積極的な考えのようですし、状況に応じてそれが必要になる場面も確かに存在するはずですが、私は本政策には賛成できませんし、実行してはいけないと考えています。
 政府紙幣に関しては、まだ無利子非課税国債よりは検討の余地はあります。これはいわば麻薬のようなものですので、下手に使用すると体を壊してしまう恐れがありますが、経済状況の悪い時に限定して十分注意して使用すれば、痛み止めのモルヒネとしても機能するでしょう。応急措置として十分注意して用い、しかもそれを元手に金を配るようなふざけたことをしないのであれば、まだ支持の余地はあります。意図や規模、用途などがはっきりしない以上、現段階ではまだ支持するともしないともいえません。
 しかし、問題は無利子非課税国債です。これは利子がつかない代わりに相続税が非課税となる国債で、与謝野氏によれば「日本は1500兆円以上の個人金融資産があるが、60歳以上に集まっている。本当に必要な人にお金を使えるようにしないといけないという同じ問題意識を持っている」とのことで、無利子非課税国債によって高齢者の多額の資産を国に還流させる意図があるようですが、与謝野氏らしからぬ単なる詭弁にしか見えません。
 相続税と無利子非課税国債については以前の記事で詳しく述べていますので、必要ならそちらを参照していただくとして、ここでは軽くおさらいをしておきましょう。いかなる場合に相続税が発生するかといいますと、まず5000万円が控除され、さらに1000万円に相続人の数を乗じた額を加算し、相続税はこれを越えた部分のみに課税されます。つまり、控除額は少なくとも6000万や7000万、多ければそれ以上となり、それ以下の相続には課税されません。
 さらに、仮にその額を超える相続が発生したとしても、超過分の1000万円までの部分には10%、1000万円から3000万円の部分には15%といった程度の税が加算されるのみで、最大課税率の50%に達するには超過分が3億円以上なくてはなりません。控除の部分は全く非課税ですし、超過部分のうち3億円以内の部分には50%より低い税率しか適用されませんので、50%なる課税は一般人にはそうそう縁のあるものではありません。実質的には、4億も相続してようやく50%の部分が多少出てくる程度でしょうか。
 したがって、大半の人には相続税など無縁のものですし、仮に課税されたとしてもわずかな額に過ぎないといえます。相続税が免除されて利益を得る人がいるとすれば、莫大な資産を持つ一部の人に限られます。格差の拡大が指摘され、派遣切りなどで日本が大きな打撃を受ける中、さらに金持ちを優遇する策が有効とは到底考えられません
 与謝野氏の発言からすれば、一部の富豪が持つ金を無利子国債に変えさせ、それを財源として弱者その他の支援を行う意図なのでしょうが、つまりは金持ちに相続税逃れの手段を提供する策に過ぎないのですから、当然ながら富を分配する機能は低下します。また、国債自体は無利子であっても、国は相続税を受け取れなくなるのですから、迂回献金ならぬ「迂回利払い」が発生するだけに過ぎません
 与謝野氏や政府としては、国債の利払いを抑制したり、あるいは無利子で受けた金を運用して利益を出すなどすれば、相続税がある場合と比べても収支をプラスにできるとの読みがあるものとも考えられます。しかし、仮にその目論見通りになり、格差を推進して金持ちを焼け太らせるような手段で多少の利益が確保できたとしても、これによって富の分配機能は損なわれ、格差の固定化が発生します。
 また、推進派もこれが課税逃れに使われる可能性は認識しているようで、譲渡制限など課税逃れを困難にする制限を設けることも検討されているようですが、そもそも「無利子」なる不利な国債をあえて買おうとする人がなぜ現れるのか分かっているのでしょうか。言うまでもありませんが、これは「相続税免除」のメリットがデメリットを補って余りあるためで、もし買ったところで損害の方が大きいようなら、金持ちはこのようなものを買おうとはしないでしょう。課税逃れも何も、そもそも課税回避をウリにしている国債である点を忘れてはいけません。金持ちがこれを購入するのは、それが金持ちにとって有利な条件であるからに他なりません。一方、本当に課税逃れができないほどの制限を課せば、メリットが存在しなくなりますので、買う人はいなくなります。
 与謝野氏は「個人資産の多くが60歳以上に集中している」点を問題視し、それを「本当に必要な人」に使用することを大義名分にしていますが、前述の通り多額の相続税を払わなければならないのはごく一部の富豪に過ぎません。60歳以上の一部の富豪の財産に課されるべき相続税を免除し、その死後に相続人が莫大な財産を丸々受け取れるようにするのが、「本当に必要な人」に金を分配する手段なのでしょうか。このような政策を実行するのと、1500兆円の大半を持つという60歳以上の一部の富豪に対してしっかり相続税を課すのでは、どちらの方が「本当に必要な人」に金を分配する方法として有利でしょうか。
 さらには、自民党内には「贈与税軽減」の話まで出てきているようです。贈与税も相続税に似た傾向のある税で、こちらは生前の贈与に対して税を課すものです。どうなるかは今後の検討次第とはいえ、これもまた金持ち優遇策の1つとなる可能性があります。格差の固定化などが問題になっている中で、なぜこの期に及んでこのような政策を連発するのか、非常に理解に苦しみます。
 与謝野氏は実力者のはずなのですが、麻生内閣でも経済ポストの重役にありながら、なぜ金配りを何としても阻止しなかったのかも気になります。金配りが日本のためにならないことなど、与謝野氏ともあろう人なら最初から分かっていたはずです。この不況で財政出動の必要性が増し、最大級の補正予算を組まなければならない状況のようですが、法人税などの税収も大幅な下落となっており、早速問題が出ている始末です。金配りで2兆円もの金をドブに捨てていなければ、もう少しはマシになっていたはずなのです。この様子では、金配りの2兆円分の代償は、遠からぬうちに降りかかってくる可能性があります。
 与謝野氏が自民党随一の実力者であり、少なくとも無能すぎる麻生氏の何十倍という能力を持つであろうことには、異論はありません。しかし、その与謝野氏さえこのような政策論を持っているようでは、非常に不安であると言わざるを得ません。少なくとも、以上の疑問に答える程度の説明は欲しいところです。

 C言語には構造体、共用体、列挙の3つの構造があります。構造体は最も多用されるもので、これなくしてCはまともに使えません。クラスの機能限定版のようなものであるため、OOP言語では廃止される傾向にあります。また、C#やDの構造体は名前こそ同じですが、実際には全く意味が違う機能です。共用体は構造体と同類ですが、全要素の格納位置がメモリ上の同じ位置から始まる点が異なります。これはこれで局面によっては便利なのですが、OOPでは無理な共用よりもクラスの継承を用いた方が安全であるため、廃止される傾向にあります。もしOOP言語が普及していなかったら、DOMのノードはunionで実装されていた可能性があります。
 唯一生き残っているといえるのが列挙たるenumで、いわゆる定数のセットとして用いられています。C#のenumは基本的に定数とほとんど変わりませんが、タイプセーフかつOR演算可能などの長所があります。Javaのenumは作られたインスタンスの集合体で、それ自体がメソッドを保持できるため、なかなか便利です。
 ところで、関数型言語には「バリアント」なるものがあります。Haskellにもありましたが、OCamlにも用意されています。これは上記3つを全部足し合わせたような不思議なもので、当然ながらタイプセーフですし、定数としても使用でき、定数に値を持たせるような使い方もでき、共用体のように1つの型に2つ以上の機能を持たせたりもできます。
 最も単純な活用法は、enumとしての使用です。その際には以下のように定義します。
type paradigm = Procedural | Functional | Logical
 これは、paradigm型がProcedural、Functional、Logicalのいずれかを表すものとする宣言です。paradigmの先頭の文字が小文字に、Procedural以下の先頭の文字が大文字になっている点に注目してください。
 受け取り側は、ifなどの条件判定で分岐しても構いませんが、パターンマッチを使用するとより簡単です。
type paradigm = Procedural | Functional | Logical;;

let for_example (p : paradigm) : string = match p with
	| Procedural -> "FORTRAN"
	| Functional -> "OCaml"
	| Logical -> "Prolog";;

Printf.printf "%s" (for_example Functional)
 列挙なり定数なりは使う場面が多いため、これは色々な場面で使用できます。
type sort_type = Asc | Desc;;

let sort (source : int list) (t : sort_type) : int list =
	let rec in_sort source = match source with
		| x :: xs -> List.append (in_sort (List.filter ((>) x) xs))
			(x :: (in_sort (List.filter ((<=) x) xs)))
		| [] -> []
	in match t with
		| Asc -> in_sort source
		| Desc -> List.rev (in_sort source);;

List.iter (Printf.printf "%d ") (sort [5; 1; 9; 3; 6; 2; 8; 7; 4] Asc);;
Printf.printf "\n";;
List.iter (Printf.printf "%d ") (sort [5; 1; 9; 3; 6; 2; 8; 7; 4] Desc)
 これだけならenumと変わりませんが、バリアントの機能は列挙にとどまりません。それぞれにデータを持たせたりもできるため、unionと似たような使い方が可能なのです。さらに、unionでは些細なミスから型安全性を破壊してしまう場合がありますが、バリアントなら安全です。
 以下、intまたはstringのいずれかを取るバリアントです。
type int_or_string = HoldInt of int | HoldString of string;;

let show (d : int_or_string) = match d with
	| HoldInt i -> Printf.printf "%d" i
	| HoldString s -> Printf.printf "%s" s;;

show (HoldString "spam!");;
show (HoldInt 16384)
 バリアントの中身のデータは、上記のようにパターンマッチによって取得できます。unionと違って型安全で、クラスよりも手軽かつキャストやジェネリックを考える必要もないのがありがたいところです。
 また、C#のint?型、JavaのInteger型のように、無効な値をサポートする型を取るような使い方もできます。SQLではINTなど大半のカラム(NOT NULLでないもの)にNULLを格納できますが、OCamlでもバリアントを使えばそのようなものを作成できます。他の言語でいえば、HaskellのMaybeに似ています。
type maybe = Just of int | Nothing;;

(* ゼロ除算なら Nothing を返す *)
let div a b = if b != 0 then Just (a / b) else Nothing;;

let show (d : maybe) = match d with
	| Just i -> Printf.printf "%d\n" i
	| Nothing -> print_string "Nothing\n";;

show (div 10 5);;
show (div 10 0)
 しかし、このmaybeはあまり役に立ちません。機能自体は普遍的なものであるのに、型としてintしか取れないのでは、汎用性に乏しすぎるのです。例えばC#のnull許容型の場合、int?やfloat?など値型はどれもnull許容化できるようになっていますし、HaskellのMaybeも汎用的に使用できます。intだけしか取れないのでは話になりません。
 そこで使用するのが、あの'aです。基本的にはジェネリックと似ているのですが、ジェネリックが「List<Integer>」などと表記されるのとは逆に、OCamlでは「int list」の順番で表記するのが基本ですので、これにならって'aを型名の前に持ってきます。
type 'a maybe = Just of 'a | Nothing;;
 これで汎用的なmaybeのできあがりです。intでもstringでもお好きなものをどうぞ。
 OCamlのデータは基本的に値渡しなのですが、そのような言語にこの種の機能が搭載されているのは非常に助かります。同じく関数型であるHaskellにはバリアントがあり、JavaやC#のクラスは参照渡しが標準で、C++はvoid*など反則的なポインタの扱い方ができるとして、Adaは値渡しの上にこのようなスタイルは用いられません。したがって、例えば連想配列などからデータを取り出したいとして、Javaその他ではデータが存在しなければnullを返せるところを、Adaでは例外を投げるしか方法がありません。関数型、特に純粋なプログラミングが強制または推奨されている言語では、データが値渡しにされる場合が多いため、これは非常にありがたい機能です。

※09/03/21追記
 トラックバックによると、ここの部分が誤解を招くようですので、追記しておきます。
 トラックバック元の方は極めて優れた開発者の方なのですから、「このようなスタイルは用いられません」の書き方で言外の意図を解釈していただきたかったのですが、Adaでは無理と書いているわけではありません。Adaを少しでも書いた方なら、少なくとも「できない」わけではないことはお分かりでしょう。あくまで習慣的な部分に言及しているに過ぎません。ご指摘はありがたいのですが、万一この種の書き方のたびに誰かからご指摘があると、コメントやトラックバック欄があふれてしまいます。
 これは私が自作Ordered_MapをAdaで書いた際の恨み節です。標準ライブラリのOrdered_Mapでは、取得しようとした要素がなければ(nullを返してくるJavaと違って)容赦なく例外を投げてきます。必ず値があると分かっていれば良いのですが、そうでなければ血眼でContainsとElementです。用途に応じた関数を作ってかませるなどの手もありますが、次善の策です。自作の際にはどうにかならないものかと考えましたが、結局例外以外に汎用的な策がなく、標準ライブラリには到底勝てませんでした。下手に「Containsの後にElement」とすると2度のサーチが必要となり(標準ライブラリでは、まずFindをかけてカーソルを取り、No_Elementとの比較の上でElementを使うのが正解でしょうが、Javaよりもう一手間といったところです)、かといって例外を投げるのは、Javaほどの負荷はなさそうですが、手間はしっかりかかるとあって、困り果てました。
 一方、HaskellではMaybeやEitherが標準で用意されており、OCamlではoptionが習慣となっているようですので、このように書いたに過ぎません。個人的にはAdaはかなり好きな言語なのですが、私はハイパースレッディング非搭載ですので、ご指摘のたびに追記や弁解をするのはほぼ不可能です(さらには、この追記に対しての指摘も可能でしょう。仮にご指摘があるとすれば、大体どの辺りが問題となるかはおおむね予想できています)。本当は年末から最近にかけてAda第2部のネタを用意していたのですが、このブログでは当面Adaは扱わない方が良いのかもしれません。

 ところで、OCamlでは演算子のオーバーロードもサポートされています。基本的にはC++やC#などと同じものですが、それらのような一般的な手続き型のオーバーロードとは異なり、OCamlでは演算子を創作しても構いません。演算子というものが存在しないLispはともかくとして、関数型にはOCaml以外にも演算子を自作できるものが多く見受けられます。
 以下の自作演算子「+=」は、ref int型に対して値を加算代入するものです。
let (+=) (a : int ref) (b : int) = a := (!a + b);;

let oper_test = let a = ref 10 in
	a += 20;
	a += 30;
	Printf.printf "%d" !a
 maybeが実装可能な上、自作演算子まで使えるとなれば、これを作らない手はありません。以下のコードをHaskell使いの方々にささげます。
type 'a maybe = Just of 'a | Nothing;;

(* Monad クラスの >>= の機能 *)
let (>>=) (m : 'a maybe) (f : 'a -> 'b maybe) : 'b maybe =
	match m with
		| Just d -> f d
		| Nothing -> Nothing;;

(* ゼロ除算であれば Nothing を返す割り算関数
ゼロ除算でなければ Just int が得られる *)
let div (a : int) (b : int) : int maybe =
	if b != 0 then Just (a / b) else Nothing;;

(* int maybe の表示処理用の関数 *)
let show (m : int maybe) = match m with
	| Just d -> Printf.printf "%d\n" d
	| Nothing -> print_string "Nothing\n";;

(* 使用例 *)
(* A.通常の使用 *)
show (Just 10000 >>= (fun a -> div a 2) >>= (fun a -> div a 5) >>=
	(fun a -> div a 3) >>= (fun a -> div a 4));;
(* 結果 : 83 *)

(* B.途中でエラー *)
show (Just 10000 >>= (fun a -> div a 2) >>= (fun a -> div a 0) >>=
	(fun a -> div a 3) >>= (fun a -> div a 4));;
(* 結果 : Nothing *)
 モナドを使える方にとっては、実に基本的なコードでしょう。ひとたびNothingとなれば、残り全部がNothingです。OCamlは非純粋関数型言語ですし、例外の機能も備えているため、モナドのような奇策を用いなくても何とかなるのですが、そのような使い方はあまり行わないにしても、少なくともAdaのような苦労をする必要がないのは助かります。
 もしバリアントに複数の値を保持させたい場合には、タプルを使用するのが最も簡単です。
type 'a some = A of 'a * 'a | B of 'a;;
 この場合、Aを使用した場合には'a * 'aのタプルとなり、Bであれば'a単独となります。使いどころはやや想像しづらいのですが、バリアントでも合成型は扱えることが分かります。
 また、これも開発においてはお決まりの道具ですが、OCamlにはレコード型も用意されています。規模がさほど大きくなく、しかもその場限りのデータであれば、いわば無名構造体であるタプルでも特に問題は出ませんが、そうでないならレコードが便利です。
 レコードは次のように宣言します。
type person = {name : string; birth : int};;
 意味はほとんど見ての通りでしょう。構造体やレコードの宣言方法など、どの言語でもほとんど似たようなものでしょうが、ややAdaに似た印象を受けます。参考までに、Adaでは以下のようになります。
type person is record
	name : String(1..16);
	birth : Integer;
end record;
 構造体の作成は比較的簡単で、以下のようにするだけです。宣言の際に型名を記述していないのが少々引っかかりますが、そのような仕様なのですから仕方ありません。
{name = "Ada"; birth = 1815}
 構造体は以下のように使用します。
type person = {name : string; birth : int};;

List.iter (fun p -> Printf.printf "%s\t%d\n" p.name p.birth)
	[{name = "Ada"; birth = 1815};
	{name = "Grace"; birth = 1906};
	{name = "Alan"; birth = 1940};
	{name = "Larry"; birth = 1954}];;
 ここで気になるのが、もし同内容のレコードが複数存在したらどうなるかという点です。このような現象はそうそう起こらないはずですが、なにぶん型を指定せずにオブジェクトが作れてしまうのですから、かぶってしまう可能性が全くないとはいえません。例えば、
type person = {name : string; title : string};;
type book = {name : string; title : string};;
 このようなレコードを作成したとしましょう。personの場合、titleは「肩書き」の意味です。bookのnameは著者名、titleは書名です。これらは明らかに別のものですが、型指定なくしては区別する方法がありません。宣言だけならエラーなく受け入れてくれますが、使用した際には一体どうなるのでしょうか。
type person = {name : string; title : string};;
type book = {name : string; title : string};;

let show_person (p : person) = Printf.printf "%s・%s氏\n" p.title p.name;;
let show_book (b : book) = Printf.printf "%s著 %s\n" b.name b.title;;
 4行目でエラーが発生してしまいました。「This expression has type person but is here used with type book」(この式はperson型を持っているが、使われているのはbook型だ)とのことです。どうやら後から登録されたbookによってpersonの要素が上書きされてしまったらしく、p.titleがbookの要素とみなされてしまっているようです。
 さらに悪いことに、OCamlではどうやらレコードの要素は同じ名前を持つだけで危ないようです。例えば以下のコードは、かなり簡略化しているとはいえ普遍的なものですが、
type person = {name : string; title : string};;
type product = {name : string; price : int};;

let show_person (p : person) = Printf.printf "%s %s氏\n" p.title p.name;;
let show_product (b : product) = Printf.printf "%s:%d円\n" b.name b.price;;
 これでもなおエラーが発生してしまいます。どうやらperson.nameが後から登録されたproduct.nameによって上書きされてしまったらしく、4行目のnameへのアクセスがproductに対するものとみなされてしまい、型エラーが発生します。非常に不便なのですが、何とかならないのでしょうか。
 本当はこの時点で取り上げるべきものではありませんが、どうやらモジュールによってネームスペースを区切るしかないようです。なお、通常のモジュールはファイルごとに記述されるのが普通であり、以下のようなモジュールは「サブモジュール」と呼ばれるようです。
(* 個人データ用のモジュール *)
module Person_Module = struct
	type person = {name : string; title : string}
end

(* 書籍用のモジュール *)
module Book_Module = struct
	type book = {name : string; title : string}
end

(* 非常に手間がかかるモジュール名の記述 *)
let show_person (p : Person_Module.person) = Printf.printf "%s・%s氏\n"
	p.Person_Module.title p.Person_Module.name;;
let show_book (b : Book_Module.book) = Printf.printf "%s著 %s\n"
	b.Book_Module.name b.Book_Module.title;;

(* 使用例 *)
show_person {Person_Module.name = "イチロー";
	Person_Module.title = "とうしゅ"};;
show_book {Book_Module.name = "麻生太郎"; Book_Module.title = 
	"とてつもない日本 フロッピー1枚でコンピュータをつなぐ技術"};;
 これで無事に、イチロー氏のデータが個人データとして表示され、麻生氏の著書が書籍データとして表示されます。Cですら異なる構造体間の同じ名前は同一とはみなされないのに、より後進のはずのOCamlにおいてそれができないのは非常に不便ではありますが、基本的にincludeしさえすればすべて同一名前空間に置かれてしまうCと違い、OCamlではモジュールで機能と名前空間を細分かできますので、おそらく実用上は問題にならないのでしょう。
カテゴリ [開発魔法][社会問題][経済・知的財産] [トラックバック 1][コメント 0]
<- 前の記事を参照 次の記事を参照 ->

Trackback(1)
[Ada] 勝手に補足(from Note) - 2009/03/18(Wed)22:47:46
最近Adaの解説を書いている人が多い気が。驚くべきことにサンプル数2でも有意な(ry インドリさん yamicha.comさん これ自体は非常に喜ばしいことなのですが、明らかに試しながら書かれているにも関わらず解説口調のため、一度突っ込みたくなると止まらず……というわけで勝


- Blog by yamicha.com -