Hatena::Groupcadr

わだばLisperになる このページをアンテナに追加 RSSフィード

2004 | 12 |
2005 | 01 | 02 | 07 | 10 | 11 |
2006 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 11 |

2007-12-31

Practical Common Lisp (17)

| 12:10 | Practical Common Lisp (17) - わだばLisperになる を含むブックマーク はてなブックマーク - Practical Common Lisp (17) - わだばLisperになる

引き続きPractical Common Lisp 第4章4. Syntax and Semanticsを読んでメモしてみています。やっと4章が終った。この先が思いやられる。

Practical Common Lisp を読む - mokeheheのScheme日記 - sicpさんもPCL読書記録開始とのことで、xyzzyで取り組まれるとのこと。多分、日本でCommon Lisp系で一番ユーザが多い処理系は、xyzzyじゃないでしょうか。xyzzy周辺は面白いことをやってる人も凄い人も多い気がします。MP3のストリーミングサーバとか後半戦はきつそうですが、xyzzyは結構色々拡張してる人が沢山いて想像以上になんでもできるっぽいので、どういう風になっていくのか楽しみです。

Formatting Lisp Code

  • コードの整形というものは、厳密には文法にも機能にも関係はないものの、コードのスムースな読み書きには重要な事項。
  • Lispコードについていえば、まず重要なのはインデント
  • インデントはLispのコードの機能的構造が良く反映されていて、対応する括弧を勘定したりなどという無駄が発生しないようにすべき。
  • 一般には、コードがネストする場合、インデントは一段深くなる。改行が必要な場合は、同レベルは同じ深さで揃えられる。例えば、下の例ように。

(some-function arg-with-a-long-name
               another-arg-with-an-even-longer-name)

  • マクロとスペシャルフォームは、すこし違っていて、本体部が、2つのスペースで字下げされる。

(defun print-list (list)
  (dolist (i list)
    (format t "item: ~a~%" i)))

  • とはいえ、インデントについてあれこれ悩む必要はなく、SLIMEのような開発環境は適切に字下げの面倒を見てくれる。エディタのようなソフトウェアがインデントを解析する場合、非常に容易に解析できるのがLispの文法のアドバンテージでもある。
  • SLIME(Emacs)についていえば、開き括弧に移動して、C-M-qを押下すると、字下げし直してくれる。関数定義全体は、C-c M-qで整形してくれる。
  • インデントについてのエディタの支援はただ見た目を綺麗にしてくれるという点だけではなく、タイポも発見しやすくしてくれる。たとえば、下記のようなコードがあったとして

(defun foo ()
  (if (test)
    (do-one-thing)
    (do-another-thing)))

  • testの後に括弧を忘れた場合、下記のようにインデントされるため発見が容易になる。

(defun foo ()
  (if (test
       (do-one-thing)
       (do-another-thing))))

  • 他にコードの整形で重要なこととしては、閉括弧はリストの最後にくっつけること。下記のようには書かないこと。

(defun foo ()
  (dotimes (i 10)
    (format t "~d. hello~%" i)
  )
)

  • 最後の)))の連続はそら恐しく感じるが、適切にインデントされたLispコードの括弧は邪魔に意識されることはない筈。
  • 最後にコメントの付け方。1〜4つのセミコロンを使い分け、各々の範囲によって数が変わる。

;;;; Four semicolons are used for a file header comment.

;;; A comment with three semicolons will usually be a paragraph
;;; comment that applies to a large section of code that follows,

(defun foo (x)
  (dotimes (i x)
    ;; Two semicolons indicate this comment applies to the code
    ;; that follows. Note that this comment is indented the same
    ;; as the code that follows.
    (some-function-call)
    (another i)              ; this comment applies to this line only
    (and-another)            ; and this is for this line
    (baz)))

どうでも良いメモ

CLtLでも註釈について書いてて上記と大体同じなんですが、行を継続させる場合は、一文字下げるとか書いてます。それで、一つの;の場合は、スペースなしで直接書き始めてる感じです。最近のコードではあんまり見掛けることは無いんですが、7、80年代のMITのコードではその慣習で書いてることがたまにあります。何れにせよコメントの付け方ってあんまりこだわって書いてる人も多くない気はしますが…。


;;;; Four semicolons are used for a file header comment.

;;; A comment with three semicolons will usually be a paragraph
;;; comment that applies to a large section of code that follows,

(defun foo (x)
  (dotimes (i x)
    ;; Two semicolons indicate this comment applies to the code
    ;; that follows. Note that this comment is indented the same
    ;; as the code that follows.
    (some-function-call)
    (another i)              ;this comment applies to this line only
    (and-another)            ; and this is for this line
    (baz)))

という風です。殆ど間違い探し的にしか違いがありませんが…。

お題: コマンドライン引数の取得、年間カレンダー

| 10:01 | お題: コマンドライン引数の取得、年間カレンダー - わだばLisperになる を含むブックマーク はてなブックマーク - お題: コマンドライン引数の取得、年間カレンダー - わだばLisperになる

最近、アルゴリズム的な問題ばっかりだー、という意見がでてから、急にパズル的でない問題が増えてきました。

(118)コマンドライン引数

コマンドライン引数の取得は、処理系依存なので、KMRCLの紹介を投稿して終了。

良く考えれば、Common Lispでは処理系依存の処理を切り分ける記述ができるので、できるだけ多くの処理系をフォローするようなコードを書いた方が良かったと反省。

まあ、今からでも調べて投稿はできるんですが(笑)

(119)年間カレンダー

年間カレンダーを表示させる問題でこれもパズル的ではない問題。

他の言語の方をみてみると20行位で書いてました。自分には20行で書くのは無理だなーと思いつつ挑戦。

Date-Calcが使えそうだったので使ってみましたが、

無駄が多くて無理矢理気味な感じになってしまいました。

25行程度に収まったので、とりあえず良しとします。

ゲスト



トラックバック - http://cadr.g.hatena.ne.jp/g000001/20071231