PHPの関数型事情メモ

PHP 5.3 のラムダとクロージャーを活用する
https://www.ibm.com/developerworks/jp/opensource/library/os-php-lambda/index.html

$horse = function() {return "with no name";};

print $horse();

いわゆるラムダ式っぽいものは使えないものの、PHP5.3からはこのように無名関数を定義することができ、これがPHPでのラムダということになるそうですの。

また、 PHP4.0の時点でも

$horse = create_function('', 'return "with no name";');

という、どうしようもない記法も存在していたそうですの。ただ、これは本当にどうしようも無さすぎて使う気にはなれないですの。。

ちなみに、古い古いと言われるCentOSのYum標準リポジトリでも、CentOS6の時点でPHP5.3.3が入っているそうなので、上の無名関数の記法はどこででも使えると思って良さそうですの。（CentOS5とかを除けば、、）

ちょっとやる気でましたの。

PHPでよく使う構文まとめというエントリを

書こうとして数日、手が止まってしまいましたの。
PHPという言語への興味の惹かれなさが浮き彫りに…という感じですの。

使うシーンは多いので、一度、改めて整理してみることに価値はあると思うのですけど、手が動かないですの。

単文のラムダ式で出来ること出来ないことを考え中（C#6メモ）

関数型発祥らしく、計算や判定の類は書きやすく、逆に、副作用が中心になる、手続き型を強制されるような部分は（単体では）書きにくいか書けないという感じだと思いますの。

基本的に大抵のことは出来て、別関数でお膳立てしてあげれば何でも出来る、という印象ですの。（お膳立てしすぎると、最悪、ラムダ式の部分がただのラッパーになるというのはあるにしろ、、）


また、C#7からは、式中で変数の宣言が出来るようになったそうで、逆に言えば、C#6ではそれが出来ないですの。

でも、単に変数を加工していく感じを真似るだけなら、selectでメソッドチェーンしていく構造にする手も。あまり意味はないかも知れないけれど。

例えば、引数で数値をもらって、それを要素１つのIEnumerableに変換してselectを繰り返して、最後に数値に戻して返す。

public int getPiyo(int x) => Enumerable.Repeat(x, 1).Select(c => c * 2).Select(c => c / 2).First();

意味があるかはともかく、一応出来るようですの。

ちなみに、この例のような数値計算なら
public int getPiyo(int x) => x * 2 / 2;
と書くのが圧倒的に素直ですの。

趣味と実益、見た目の迫力を求めて（C#）

+ 日本語コーディングしようぜ
http://www.flat7th.org/~keizo/wiki/code2/KyDml6XmnKzoqp7jgrPjg7zjg4fjgqPjg7PjgrDjgZfjgojjgYbjgZw

日本語コーディング、そういうのもあるのかですの。

大会かなにかで賞金が成績によって決まるものがあったとして、
参加者が１０人未満なら成績の合計、１０人以上なら成績の平均の１０倍が賞金になるとき、それを求めるクラスメソッド、

public int getBonus(IEnumerable scores)
{
　if (scores.Count() < 10)
　{
　　return scores.Sum();
　}
　else
　{
　　return (int)scores.Average() * 10;
　}
}

これを、ラムダ式と日本語コーディングにおまけで三項演算を加えて書くと以下ですの。

（一行版）
public int get賞金(IEnumerable 成績s) => 成績s.Count() < 10 ? 成績s.Sum() : (int)成績s.Average() * 10;

（改行を入れた版）
public int get賞金(IEnumerable 成績s) => 
成績s.Count() < 10
? 成績s.Sum()
: (int)成績s.Average() * 10;

量的に少ないせいか、思ったより迫力がないですの。むしろ最初のコードより短くて見やすい気もしますの。
ただ、わらわがC#の標準の中括弧の付け方（BSD/オールマン・スタイル）が嫌いなこともあって、そもそも中括弧を使わないで済むというのはとても爽快ですの。

使いそうなLinq関数のメモ

使いそうなLinq関数

Select(式)（シーケンスを加工する）
Where(式)（条件を満たす要素を取得）
First()（先頭の要素を取得）
All(式)（すべての要素が条件を満たすか）
Any(式)（条件を満たす要素が１つでもあるか）
ToArray()（配列に変換）
Constains(値)（条件に一致する要素があるか）
ElementAt(値)（指定番目の要素を取得）

C#6のラムダ式メモ

クラスメソッドとして書く場合は、
public int a(int n) => n + 1;
のような短文形式のみ可能で、
public int a(int n) => {(略); return n};
のようなブロックで囲う複文形式は許可されないですの。

同様に、if文は使えない…けれど、三項演算子は使えるようですの。
public int a(int n) => n == 1 ? 1 : 0;


式形式のメンバー (C# プログラミング ガイド)
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members

式本体の定義のサポートは、メソッドとプロパティの get アクセサーのために C# 6 で導入され、C# 7.0 で拡張されました。 

とあるように、基本的には簡単な（？）getアクセサ用にあるようですの。

Unity2018.1 リリース覚書

Unity 2018.1 リリース
https://blogs.unity3d.com/jp/2018/05/02/2018-1-is-now-available/

スクリプトのアップグレード .NET 4.x
新しいスクリプティングランタイムは Unity 2018.1 では試作版ではなくなり、安定スクリプティングランタイムの初回プレビュー版となります。
（中略）
例えば、C# 6 と新しい .NET API によって、Unity にモダンな .NET ライブラリやツールとの互換性がもたらされます。

MonoDevelop の廃止

Unityに依存している限り、言語の最新バージョンを常に使えないのは苦しいけれども、これでひとまずC#6までは安心して使えるようになったようですの。

わらわはMonoDevelop好きだったので、廃止は残念ですの。

飛べない豚がただの豚なら

ろくなプログラムを書いていないせいか、
ろくにプログラムを書いていないせいか、
最近、プログラミング能力が上がるどころか地に落ちている気がしますの。

関数型言語の美しさに触れてからというもの、オブジェクト指向の醜い部分が気になってしかたがなく。オブジェクト指向を捨てたはいいものの、関数型を実用できるほどの力も環境もなく。

いっとき、C#のLinqに賭けたものの、期待したほどの力はLinqには無く。

今はただ、PHPあたりでゴミクズのようなコードを書くばかり。

プログラミング自体もまあ好きだったけれど、やっぱりその前に、プログラミングで好きなものを作るのが好きだったのかな、と、素朴に思うのですの。いまごろになって。

どうでもいいものを、どうでもいい感じで作りすぎたせいなのか、好きなものをプログラミングすることさえちょっと抵抗感を感じてしまう今日このごろですの。

新しいことを学ぶこと自体が嫌になったわけではないのですけど、IT関係で新しいことを学ぶ意欲は激減していますの。いろんな技術書を見ても、わくわくするどころか、ふーんそれで？ってなってしまいますの。

よくIT辞めた人が農業にいくのわかるきがしますの。食べ物にはわかりやすく価値があるけれど、ITはわかりやすい価値からもっとも遠い。わらわは頭が悪いので、その価値がわからなくなってきましたの。

わくわくが欲しい。さもなければ、お金が欲しいものですの。

祝、西暦で統一

省庁データ、近く西暦で統一…来春は間に合わず
https://headlines.yahoo.co.jp/hl?a=20180520-00050149-yom-pol


良いことだと思いますの。でも、書類などに出力するときは今まで通り和暦で出すらしくて、口惜しい感じですの。いっそ全て西暦にしてしまえばいいのにですの。

そもそも和暦がなぜ必要なのか。いまだに、わらわは西暦→和暦の変換を暗算では出来ないですの。ものすごくたまにしか使わないからですの。

ときどき、なぜわざわざキリスト教の暦を使わなければならないのかと言う人がいるのですけど、それは改元がないからですの。改元さえ無いのなら和暦でもいいけれど、それがある以上、和暦は使用に適さないですの。

もしどうしても和暦を使いたいのなら、改元を捨てるしか無いですの。つまり、今からでも「平成からは改元なし」とするのですの。そうして平成500年、平成2500年…となっていくのなら、まだ許容範囲ですの。過去については西暦と併用するとしても。

一方で、もし文化的な意味で、和暦を今まで通りの形で「残したい」のなら、実用に使うことは辞めたほうがいいですの。実用に使う道具は必ず、使う人の要望で変わっていくものですの。

国家施設の飾りや、国家イベントの旗にだけ書かれるような、そういう非日常で非実用な、象徴的な存在になればいいと思いますの。和暦の基準になっている天皇がそうであるように。


…と思ったとき、ふと、
天皇の状態変化が、使用を義務付けられている暦にクリティカルな変化を及ぼすという構造は、天皇は象徴でなければいけないという制約からやや逸脱するのでは？と思ったのですの。

そしたら、公文書での和暦の使用は特に法令などで義務付けられているものではなく、ただの慣習らしいですの。なるほど、ならセーフだと思いますの。頑なに和暦だから義務なのかと思ってたですの。

しかしそれなら、なおのこと西暦に統一するか、せめて記入欄に西暦も印刷してどちらで書いても良いようにしておいて欲しいものですの。どうせもう中身は西暦になるのだし。