Programmer's Note

コード読み書きの備忘録。

Clojureを遊ぶ：リストとマクロ

Clojure

「７つの言語７つの世界」 を読んでClojureを始めた。

まったく思考がLISPerになってなく、すらすらプログラムが組める状態ではない。が、実に面白い。

Clojureの強力な点は、コレクションに対する操作を、非常に簡潔に書けるところだ。

まずはリスト。

リストは(list 1 2 3)と書く。あるいはリーダーマクロの'を使って'(1 2 3)と書く。

user=> (def a '(1 2 3))
#'user/a
user=> a
(1 2 3)
user=> (take 2 a)
(1 2)

LISPのプログラムそのものがリストで構成されているデータで、

user=> (def b '(println 1))
#'user/b
user=> b
(println 1)
user=> (eval b)
1
nil
user=>

なんか、これだけでミニマクロみたいなものだな。

本当のマクロを使ってみる。

user=> (defmacro hello [txt] (println "Hello," txt))
#'user/hello
user=> (hello "Clojure")
Hello, Clojure
nil

これくらいなら、普通に関数を定義すればよさそうだ。 実際やってみる。

user=> (defn hello_f [txt] (println "Hello," txt))
#'user/hello_f
user=> (hello "Clojure")
Hello, Clojure
nil

同じ結果が出る。

しかし、以下で明確に処理の違いが分かる。

user=> (hello (print 1))
Hello, (print 1)
nil
user=> (hello_f (print 1))
1Hello, nil
nil

マクロの場合は引数を評価せずに、そのままリストとして渡すのに対して、 関数の場合は引数を評価してから渡す。

というところまでは分かったが、まだまだ感覚をつかめていない。

マコネル本の読書

遅ればせながら、最近やっとCode Completeを読んだ。まだ上巻を読了したばかりだが、この本がこんなに面白いとは思わなかった。

ずいぶん前に買って積んでいたが、言わば食わず嫌いだったな。なぜかって一言で言えばMicrosoft Pressだから。
この本は名著ともっぱら評判は良いみたいだけど、MSの人が書いたっぽいからつまらないに違いない。と思い込んでた。反省。
MSの製品はつまらないが、必ずしも出す本はつまらない訳じゃないのね。
(著者のSteve McConnelさんは、厳密にはMSのプロジェクトに関わってたが社員じゃなかったようだ)
元MSの人でやはり面白い本を出してるJoelさんの例もあって、最近はすっかりMSに対するイメージがアップしている。

さて、McConnelさんの他の著作で、エッセイ的なProfessional Software Developmentを今読んでいるが、これも面白い。この人は重厚に文献を読んで分かりやすく本質的な問題を分析する人だなと。

とりあえず前半で「ソフトウェアはソフトではない(変更が簡単だと思うど素人の多いこと)」「銀の弾丸は失敗する(組織がプロセス改善の流行に流されたらおしまいよ)」。
まあ原文ままではないが、そんなことを言っていて、読んでため息し膝を打つのだった。いやまさに、あるある。だなあと。

sicpの導入部

sicp 読書

MITのプログラミングの授業で使われていた伝説的な教科書、「Structure and Interpretation of Computer Programs」、略してsicpを読み始めた。
いわゆるプログラミングの古典的名著として数えられ、「ハッカーと画家」のポール・グレアムもAmazonレビューで絶賛している。(というかLISPerにとってはバイブルなのかしら。)
内容的に課題として小難しい数学の問題を解いたりとあるみたいで、どこまで続くか分からんが、楽しく読んでいきたい。
というか、導入文はもうえらく名文である。実にわくわくする。
Wizard本*1と呼ばれているらしいが、この冒頭ではComputer Programを魔法のスペルに喩えているのだ。

    A computational process, in a correctly working computer, execute programs precisely and accurately. Thus like the sorcerer's apprentice, novice programmer must learn to understand and to anticipate the consequence of thier conjuring.
    Fortunately, learning to program is considerably less dangerous than learning sorcery, because the spirits we deal with are conveniently contained in a secure way.


教科書でこのユーモアかつ想像力に富んだ導入は日本では考えられない。
古くは数学、科学が占星術、錬金術と同等に列していた西欧の感覚が織り込まれていて、なんともロマンを感じる。

*1:本書の表紙が魔法使いの師匠と弟子の絵になっているのもWizard本と言われるゆえんだろう

vimrcメモ

vim

vimrcメモ。 プラグインも色々入れていたが、使用頻度が低いので思い切って削って、とりあえず必要最小限のものだけを残してみた。 運用していくうちにまた増えたりするかもしれんが。

だいたいがネットで検索した設定をコピペして、ミックスした感じだが。

set nocompatible

" Enable file type detection and do language-dependent indenting.
filetype plugin indent on

" Switch syntax highlighting on
syntax on

" Show line numbers
set number

" C indent setting
set cindent
set cinoptions+=:0 "Change indent rule of 'case' statement

" Tab width, no expand to space
set tabstop=4 shiftwidth=4 noexpandtab

" Highlight search word, increamental hightlight
set hlsearch
set incsearch

" Command Make will call make and then cwindow which
" open a 3 line error window if any errors are found.
" if no errors, it closes any open cwindow.
:command -nargs=* Make make <args> | cwindow  3
:map <Leader>j :Make<CR>

autocmd QuickFixCmdPost [^l]* nested cwindow
autocmd QuickFixCmdPost    l* nested lwindow

" for GLOBAL indexing
map <C-g> :Gtags
map <C-h> :Gtags -f %<CR>
map <C-f> :GtagsCursor<CR>
map <C-j> :cn<CR>
map <C-k> :cp<CR>

yacc を遊ぶ：パーサーの動き確認

yacc yacc

「THE UNIX PROGRAMMING ENVIRONMENT」のチャプター８のhocをサンプルに、yaccのパースの動きを確かめてみる。

この本では、hoc4でパーサーからインタプリタコードを生成するステップに移るが、 生成すべきコードとの結びつきがイマイチ想像できんかったから。

とりあえず、サンプル：

[hoc.y]

%{
#include <stdio.h>
#include <ctype.h>
#define YYSTYPE double
%}
%token NUMBER
%right  '='
%left   '+' '-' /* left associative, name precedence */
%left   '*' '/' /* left assoc., higher procedence */
%%
list:   /*nothing*/
        | list '\n'         { printf("list\n"); }
        | list expr '\n'    { printf("list expr: %f\n", $2); }
        ;

expr:   NUMBER              { printf("NUMBER: %f\n", $1); $$ = $1; }
        | expr '+' expr     { printf("%f + %f\n", $1, $3); $$ = $1 + $3; }
        | expr '*' expr     { printf("%f * %f\n", $1, $3); $$ = $1 * $3; }
        | '(' expr ')'      { printf("( %f )\n", $2); $$ = $2; }
        ;
%%
int main(int arc, char **argv) {
    yyparse();
}
int yyerror(char *s) {
    fprintf(stderr, "%s\n", s);
}
int yylex() {
    int c;

    while ((c=getchar()) == ' ' || c == '\t') {
        ;
    }
    if (c==EOF) {
        return 0;
    }
    if (c=='.' || isdigit(c)) { /*NUMBER*/
        ungetc(c, stdin);
        scanf("%lf", &yylval);
        return NUMBER;
    }
    return c;
}

[Makefile]

TARGET = hoc
OBJS = y.tab.o

all: $(TARGET)

$(TARGET): $(OBJS)
    gcc $(OBJS) -o $@

y.tab.o: y.tab.c
    gcc -c $< -o $@

y.tab.c: hoc.y
    yacc $<

clean:
    rm -f y.tab.c
    rm -f $(OBJS)
    rm -f $(TARGET)

さて、実行してみる。

hoc4_test $./hoc
1+2+3
NUMBER: 1.000000
NUMBER: 2.000000
1.000000 + 2.000000
NUMBER: 3.000000
3.000000 + 3.000000
list expr: 6.000000

なるほど、これ分かりやすい。 仮想スタックマシンの命令はPUSH、POP、 と演算命令なので以下のような感じかな。

NUMBER: 1.000000     :  -> PUSH (NUMBER)
NUMBER: 2.000000     :  -> PUSH (NUMBER)
1.000000 + 2.000000  :  -> res = ADD (POP() + POP()); PUSH (res);
NUMBER: 3.000000     :  -> PUSH (NUMBER)
3.000000 + 3.000000  :  -> res = ADD (POP() + POP()); PUSH (res);
list expr: 6.000000  :  -> 結果 = POP()

まあ、演算命令ADDはスタックから値を取り出すところも 命令の中に含まれるだろうが。

「The UNIX Programming Environment」読了

読書 UNIX
「The UNIX Programming Environment」読了。1月からコツコツ読んで足がけ4ヶ月。正確には第9章を残しているが、第9章はtroffの紹介で、これはまあ気が向いたら読めばよいかなと思っている。

文章整形は1980年代からはもはや隔世の感がありすぎる。恐らく今後troffは使うことはないだろうし。

逆に言えば、1章から8章まで今でも通用する内容だったということの方が凄いかもしれない。

ほんとにプログラマの作業場としてのUNIXの基礎はこの本が書かれた時代と変わらない。実にたくさんのことを学ぶことができた。

個々ツールの細かいTIPSもあるが、一冊を読み通すことでUNIXカルチャーの薫陶を受けることができたかなと思う。

KernighanとPikeが自分のチューターとして懇切丁寧にイロハを教えてくれた感じ。そういう疑似体験ができたことが何よりで、本を一冊読んだだけで成長を実感できるってそうそうないと思う。

というのも、この本はそういう風に書かれている、というのが大きい。Kernighan先生の本はどれも実用的で面白い例をベースに語っている。読み終えた頃に確実にレベルアップしている。

さて、UNIXの考え方の醍醐味は、シンプルで小さなプログラムを組み合わせれば、複雑な問題をも解決できること。
完全な解決を求める必要はないこと(問題が8割、9割解決できればいい)。
完璧なものを最初から作ろうとするのではなく、作りながら改善していくこと。
さらには自分で一から何でも作ろうとしない、すでにあるツールをまず活用できないか考えること。
など、とことん実用主義な点にあるかなと思う。
ここには、アイディアがあったらまずは試してみる、という精神に溢れている。

UNIXはそういことをやるにはベストな環境。普段使ってる環境の本質を理解してこれから使っていける。という意味でやっと入門できたかなと。


ハッカーと画家: 言語の力

読書

ちょっと衝撃を受けた。 昨日読み始めたポール・グレアムの「ハッカーと画家」、これはすごい本だ。

結構前に、Matzさんの以下の記事で知ったのだが、

まつもとゆきひろのハッカーズライフ：第3回 ハッカーと仕事 (2/2) - ITmedia エンタープライズ

ずっとブックリストに入れたままだった・・・これも早めに読んでおくべきだった。 実に色々示唆に富む内容で考えさせられる。良い本は刺激をくれ思考させてくれる本だ。

とりわけ衝撃的だったのは、「言語の力」をとうとうと説いてる章の以下の一文。

あたなが難しい問題を解こうとしているなら、問われているのはパワフルな言語を使うか使わないか、ではない。 (a)パワフルな言語を使うか、(b)パワフルな言語と等価なインタプルタを書くか、(c)自らがパワフルな言語の人間コンパイラとなるか、という選択なのだ

...

コンパイラがやるべきことを人間がシミュレートするという慣行はただ広まっているというだけでなく、思考を型にはめる作用がある。 例えば、オブジェクト指向の世界ではよく「パターン」というのを耳にするだろう。この「パターン」は多くの場合、(c)のケース、すなわち人間コンパイラが動作してる証拠なんじゃないかと私は思う。

こりゃ、こういう視点なかったな。 言語レベルでパラダイムが変われば、パターンとかフレームワークとかは、実はそもそもいらない。 このものの見方があるかないかでずいぶん違うな。