LISPMEMO
LISPUSERLISPMEMOLisp isn't a language, it's a building material. -- Alan Kay 先日 ANSI Common Lisp の bfs がわかりにくい、という話があったので。 A -> B, C B -> C C -> D で、このようなネットワークの A から C までの最短経路を求める。 (defun shortest-path (start end net) (bfs end (list (list start)) net)) (defun bfs (end queue net) (if (null queue) nil (let ((path (car queue))) (let ((node (car path))) (if (eql node end) (reverse path) (bfs end (app
CFFI 入門 (1)
LISPUSERLISPMEMOLisp is a programmable programming language. -- John Foderaro 最近の Common Lisp 界では FFI の定番といえば CFFI のようです． UFFI のプロジェクトも多いですが． 昔書いたドキュメントの例 を CFFI で試してみました． #include <stdio.h> int float_to_bits (float f) { return *((int*)&f); } int double_to_bits_hi (double f) { return ((int*)&f)[0]; } int double_to_bits_lo (double f) { return ((int*)&f)[1]; } float bits_to_float (int i) { return *(
LISPMEMO
Common Lisp による日常作業 CSV ファイルを読む (read-line, read-line-into, simple-stream-read-line とか) 以前のエントリ CSV ファイルを読むコード で、ちょろっと いかにも Scheme なコードなのでループと状態マシンに書き直すとかの高速化の余地がありますね。 今迄ちっこいファイルしか読んでなかったので、ちょっとメモリ使用量が多いなー。 まぁ、Gauche と違って immutable な文字列じゃないんで共有とかできないから効率わるいんじゃろ。 などと目を背けていたのですが、ある程度の規模の CSV を読んだら途端に性能問題が。うがぁ。 簡単に体感できる量だと 20MB 程度のデータを読み書きしてみればわかります。 (use text.csv) (length (call-with-input-file "KEN
LISPMEMO
Emacs から SLIME を起動すると (http://lispuser.net/emacs/lisphacking.html , http://lispuser.net/commonlisp/clisp.html 参照) 、 CL-USER> というプロンプトが表示されていると思います。 CL-USER> ここに、プログラムを入力することで、 Lisp にプログラムを解釈させて結果を確認することができます。 さっそく Lisp にプログラムを実行させてみましょう。 CL-USER> (+ 1 2) 3 これは、 1 + 2 を計算させるプログラムです。 (+ 1 2) の意味は、関数 + パラメータとして 1 と 2 を渡す、という意味になります。 乗算を行いたい場合には関数 * を使用してみてください。 CL-USER> (* 3 4) 12 もちろん、式を入れ個にする事もできます
Common Lisp と 日本語 と 文字コード
external-format の使い方がわかったところで、実用的には文字コードの判定処理が必要になる場合が多い。 external-format を知っただけでは、with-open-file の external-format に何を指定すればいいのか迷ってしまう。 で、いろいろ蘊蓄を語ろうと思ったのだが、ふと Gauche の文字コード判定処理を CL に移植して比較したところ 性能、精度とも私の手作りのものより断然よかったのでこっちを採用。 Gauche のソースの ext/charconv/guess.scm, ext/charconv/guess.c, ext/charconv/guesstab.c が日本語エンコーディング判定処理だ。 guess.scm で状態表 guesstab.c を出力し、 C コンパイラで guess.c guesstab.c をコンパイルしてモジュ
LispUser.net :括弧の理由 (1) -- Emacs による S 式編集支援
LISPUSERLISPMEMOLisp is like a ball of mud - you can throw anything you want into it, and it's still Lisp. -- Anonymous Lisp の括弧は良くネタにされます。実際、大量の過去は最初のインパクトは強烈だったのを覚えています。 いったいなぜ Lisper は括弧を捨てないのでしょう？ 歴史的にみれば括弧を好まない Lisper も居ます。古くは CMU の AI リポジトリに CGOL という ALGOL ライクな 構文の Lisp リーダ/ライタがあり、これは S 式と相互に変換できました。CGOL で書いて、S 式で表示とかができたわけですね。 ;;Execute by typing "cl < demo.txt". (load "parser.cl") (load "c
LispUser.net : /lisp/2007-01-28-01-54.html
LISPUSERLISPMEMOLisp is like a ball of mud - you can throw anything you want into it, and it's still Lisp. -- Anonymous 息抜きに小ネタをば。Shiro さんとこの Lisp:S式の理由 の中のネタより。 個人的には、condは (Paul GrahamがArcで提案しているように) 括弧をひとつ 省いて、(cond 述語 式 述語 式 ) でいいんじゃないかという気がします。 式に複数の処理を書きたければbeginを使うと。 (cond (predicate x) (begin (do-something) (do-something2)) (predicate y) (do-another-thing) else (do-whatever)) また、letについては、束
CL-YACC
CL-Yacc is a LALR(1) parser generator for Common Lisp, somewhat like Yacc, GNU Bison, Zebu, lalr.cl or lalr.scm. CL-Yacc は提供するシンボルを `yacc` パッケージからエクスポートしています． (use-package 'yacc) パーサーは字句解析器 (lexer) の出力を消費してゆきます．字句解析器は終端 記号のストリームを出力します． CL-Yacc は字句解析器が二つのシンボルを返 す，引数を取らない関数である事を仮定しており，字句解析された結果を構文 規則から導かれたアクションへと渡します．字句解析器は入力情報がなくなっ たら，単に `nil` を返さなければなりません． 非常に単純な，リストからトークンを取りだしてゆく字句解析器を示します． (defu
Emacs による Lisp Hacking
SLIME の公式ページ から入手可能です．現在は ArmedBearCL, AllegroCL, CLISP , Corman Lisp, CMUCL, ECL, LispWorks, OpenMCL, SBCL, Scieneer Common Lisp といった処理系に対応．( Scheme48 に対応した SLIME48 もあります) 別プロセスで起動した lisp 処理系とソケット経由で通信する 関数の引数表示 シンボルの補完機能 ( **例：** ``m-v-b TAB => multiple-value-bind`` ) コマンド一発で HyperSpec が引ける コンパイラの note, warning, error をソース上で示してくれる（下線が引かれて，カーソルを合わせると詳細がでる） 親切なデバッガ（バックトレース上でカーソルを合せると詳細が表示されたりとか） 現
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TOP PAGE