tmuxからのpowerlineで優勝せえへん?
メモです.
現状イマイチなところがありありなのでどうにかしたい.
環境
以下に同じ端末環境を作りたかった.
zsh
prezto
を入れる.
入れたら.preztorc
のcompletionとかその他のあれこれをオンにする.
promptでテーマを変えられる.
自分は今はsorinにしてる. 色のついた矢印がかわいい.
tmux
.tmux.conf
を作って色々書く.
自分はprefixをC-z
にして, さらにemacsっぽいキーバインドを設定したりした.
powerline
tmuxとかzshとかvimとかのpowerlineは全てpowerlineという名前で1つに統合されたらしい.
しかしまだ古い情報(tmux-powerlineとか)が結構ヒットするので注意.
$ pip3 install --user powerline-status
で入れる.
pipをMacの場合はbrewで入れることになると思うけど, その場合は--user
はつけてはいけないって誰かが言ってた気がするけど普通に入ったので多分問題ない.
tmux(とzsh)にpowerlineの設定をする.
- tmux: Other plugins — Powerline beta documentation
- zsh: Shell prompts — Powerline beta documentation
これでtmuxを再起動orリロードすれば反映されているはず.
されてなければ
$ powerline-deamon -r
とかするといけるかもしれない.
テーマを変えたりする場合はconfig_filesをコピーして~/.config
以下の方を触るようにする.
しかし, 新しいsegmentを追加(電池残量とか)しようとするとcolorschemeに定義がないと言って怒られたりするし, colorschemeについての説明も公式ドキュメントに全然ないのでよくわからない.
# Linux $ cp -r ~/.local/lib/python3.5/site-packages/powerline/config_files/ ~/.config/powerline/ # Mac $ cp -r /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/powerline/config_files/ ~/.config/powerline
まぁ, powerlineはデフォルトでもそれなりに使えるので良いと思う.
.tmux.conf
をいじっても見た目変えられるっぽいし.
最終形態
優勝?
優勝には程遠い感じ.
変えたいところ:
- tmuxのpowerlineのテーマ
- preztoは果たして必要なのか? (zshにpowerlineを入れておいてそれを自分で改造すればよくない?)
- preztoやめるならzsh関係のプラグインはzplugとかで管理するか?
なんかいまいちイケてないので模索していきたい.
参考
React ComponentにImmutable.jsは(多分)だめ
ここにもはっきり書いてあるように,
Note that state must be a plain JS object, and not an Immutable collection, because React's setState API expects an object literal and will merge it (Object.assign) with the previous state.
React ComponentのstateをImmutableデータ構造にするのは良くない.
これをするとsetStateで渡ってくるものが(型情報的には確かにImmutable.Listでも)JSArrayになってたりする.
ググったら以下の2つの方法をとっている人が多かった.
- setState内では全ての
state.piyo
をImmutable.DataType(state.piyo)
みたいにラップする
これは一見うまく行くように見えて, たまたまラップすることを忘れたりするとImmutable.List.unshift
じゃなくてArray.unshift
が発動したりして死ぬ可能性がある.
- state一つ一つをImmutableにするんじゃなくてstateをまるごとImmutable.Mapにする
これはデータの取り出しがImmutable.Map.get("nyan")
みたいになるので(型をつけている場合は)型情報が消滅するので自明にダメ.
なお一瞬だけMapのKeyにString Literal Typeを渡すみたいなのも考えたけど, 与えられたデータ構造からString Literal Typeをメタ生成するとかできるんだろうか. できてもやりたくはないけど.
他にいい方法があるなら知りたい.
(やはりTypescriptでも型レベルMapを作るしかない)
(ていうかこんな分かりやすいトラップがあるのにImmutable.jsはReactと相性がいいって言ったやつ誰だよ)
(interfaceの貧弱っぷりを見るにつけてもTypescriptはまだまだ改良の余地アリアリな感じがする)
variable-free type theoryの圏論的な解釈について
の続き. いくつか疑問が解消されたのでそれについて.
var-free type theoryについて
- syntaxはcontext, type, term, substからなる.
- contextはtypeの有限列(通常はvariableとそのtypeの組の列だが, 今回はvariable-freeなのでtypeだけの列になる).
- typeはground typeと関数型
A → B
とsubstが代入された型(σ[s]
の形をしているもの)のいずれか. - termは
1
と代入された項M[s]
のいずれか. - substは
id
と合成f . g
とshift↑
とextension<f:subst, M:term>
のいずれか.
termは型付けをde Bruijn indexで考える.
term1
はcontextの直近のtypeに対応する項とみなす. 例えば, Γ,σ ⊢ 1:σ
などである.
substはcontextの間の変換とみなす.
例えばΓ ⊢ id:Γ
はid(Γ)=Γ
を表す. また, 合成は通常と逆向きに書くらしい(多分見やすさの都合).
shift↑
はindexをすべて1つ加算するような変換とみなす. 例えばΓ,σ ⊢ ↑:Γ
はindexが上に1つずれるので一番新しいtypeσ
を忘れるものとみなす.
extensionのtyping ruleは次のようなものである:
Γ ⊢ f:Γ', Γ' ⊢ σ, Γ ⊢ M:σ[f] ⇒ Γ ⊢ <f,M>:Γ',σ
これは, Mによってcontextに新しいtypeを付け加える操作と考えることができる.
あるいは, 変換fをMによって拡張したものとみなしてもよい.
locally cartesian closed categoryでの解釈
ML theoryはLCCCとイイカンジに対応する.
ここではcategory with attributesを使った解釈を使うことにする.
すると上で導入したsyntaxはLCCC(cwa)でいい感じに解釈できる.
- contextはobject, context
Γ
のtypeはΓ
-cod morphismとみなす. - type Aをもつtermは, Aに対応するmorphism(shift)のsection.
- substはmorphismとみなす.
以上の対応で, 上のsyntaxはcwaの構造で超いい感じになる.
- function type
→
はPi-typeを使って定義するので一旦忘れる. (論文にあるようなcwaを構成するとdependent product/sum, extensional identity typeを持つ) - subst
id
はidentity, 合成はcompositionになる. - shift
↑
はcwaのcanonical projection operatorになる. - 代入された項
M[s]
(M:Γ → Γ,A
,s:Γ'→Γ
)はpullbackΓ'×Γ,A[s]
overΓ
のUMPから誘導されるmorphism - extension
<f,M>
はpullbackの対角線にあたるmorphism(Mとfのliftを合成する). 1=<id,id>
はpullbackのUMPからつくる.
Set model
上のだけだとよく分からないのでSetで解釈する.
- shiftはshift写像
<gi,a:A> ~> <gi>
- termはこのsectionなので, A型の値の追加,
<gi> ~> <gi,a:A>
になる. これはa:A
と同一視できる. - 代入項に登場するpullbackは
Γ'×Γ,A[s] = {(gi', gi, a) | s(gi')=gi, a=M} = {(gi',M)}
と同一視できる. - よって
M[s]
は<gi'> ~> (<gi'>,M)
とみなせる. - extensionは
<f,t:A> = ↑*f . t ; <gi'> ~> <gi',t> ~> <f(gi'),t>
になる.
特に特徴的なのはextensionの拡張で, fによる変換をtで拡張したもの, i.e. fの変換に加えてtの値を写像に追加するものと考えることができる.
extensionっぽさがあってとてもよい.
余談
もともとML type theoryのcwaでの解釈の話を調べていてvar-free syntaxが出てきたので何かしら関係はあるのだろうと思っていたけど, ちゃんと直感的にいい感じに対応していて超すっきりした.
ついでに, 普通のλ計算とvar-freeなλ計算の変換を具体的に構成したい.
さらに気が向いたらproof formalizationもしたい.
参考文献
- https://ncatlab.org/nlab/files/CurienGarnerHofmann.pdf variable-free syntaxの出処
- http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.4410 category with attributesによる解釈
- http://iso.mor.phis.me/archives/2011-2012/stage-2012-goteburg/report.pdf extension, shiftの記法や圏論での解釈のアイデアは主にここから