lispに関するusr_kouheiのブックマーク (8)

  • 計算機プログラムの構造と解釈 第二版

    [ 目次, 前節, 次節, 索引 ] 2014-03-06 更新 [ 目次, 前節, 次節, 索引 ]

  • Flatline

    ここには特に何もありません. 主だった情報は学校に置いてある私のサイト user.ecc.u-tokyo.ac.jp/~t50473 を参照のこと. On Lisp邦訳草稿のコピー. onlisp_j.pdf onlisp_j.tex onlisp_j.cls ChangeLog HTML版 komaba.utmc.or.jp 内で検索 WWW全体から検索

    usr_kouhei
    usr_kouhei 2007/06/16
    onLisp
  • Karetta|Gaucheプログラミング(立読み版)

    はじめに書の構成 (1)書の対象読者書の表記書の使い方執筆時点でのGaucheバージョン謝辞第1部: 思想LispとScheme (4)Gaucheの特徴 (1)すべて式であるすべてリストである (1)lambdaは空気のような存在である (2)プログラミングとは名前付け(bind)であるすべて再帰である (2) (2)Schemeのすごい点 (4)すべてオブジェクトである (もしそれがお望みなら)Gaucheの設計思想や誕生の背景Schemeの評価モデルとは? (3)「Lisp脳」の謎に迫る - Schemeプログラマの発想第2部: 実用Schemeスクリプトを書こうSchemeスクリプトを書く (1)コマンドライン引数の値を得るユニットテストを書く (1)CGIを書こうSchemeスクリプトをCGIとして実行するwww.cgiライブラリを利用する (1)手軽にHTMLを生成する

  • Karetta|Gaucheプログラミング|「Lisp脳」の謎に迫る - Schemeプログラマの発想

    この原稿の最新版について この原稿に加筆した最新版が書籍「プログラミングGauche」に収録されています。 引用や紹介をされる方はなるべく書籍収録版を参照してください。 他の言語のプログラマがSchemeプログラムを書くとき、 どうしても発想が手続き的(procedural)になりがちです。 LispプログラマやSchemeプログラマの発想は手続き的な発想とはどうも違うらしい、 ということは分かるのですが、具体的に何が違うのでしょうか? ここではこの謎に迫ってみましょう。 実例 例えばこんな例題があります。 1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。 どうしてプログラマに・・・プログラムが書けないのか? (原題: Why

  • どう転んでもLisp

  • http://user.ecc.u-tokyo.ac.jp/~t50473/onlispjhtml/

  • Lisp:S式の理由

    S式は人に優しいか Shiro: Lispの不人気の理由として筆頭に上げられるのが、括弧だらけの 独特の見た目。とっつきにくい、一般的な表記法と違っていてわかりにくい、 等々、様々なことが言われてきました。しかし、 S式を捨てたLispも開発されましたが 流行ったとはいい難く、Lispな人々はいまだに括弧に固執しているかのようです。 S式のメリットをLisperに尋ねれば、エディタがどうの、マクロがどうの、といった 回答が真っ先に返って来ると思うんですが、そういう理屈をいくら理解しても S式がダメな人がS式を好きになったりはしません。どうも、もっと根的な 感覚に大きな隔たりがあるような気がします。非Lisperから理解しがたい、 Lisperの持つ感覚とはどんなものなんでしょうか。Lisp脳から見た世界は どんなものなのでしょうか。 構文木を人間が書く? S式は言ってみれば言語の構文木そ

  • Schemeを作ろう 第1回

    Last update 1999/08/07 Scheme処理系の制作 第1回 (C)平山直之 無断転載は禁止、リンクはフリー 誤字脱字の指摘は歓迎 ゲームとスクリプト はい、また例によって行き当たりばったりな企画です。 といっても、相当長い間私の心の大きな部分を占めていた問題ではあります。 それは言語の処理系の必要性についての問題です。 ゲーム制作、特にRPG・アドベンチャーなどの「シナリオ」の重要性が高いものを作るのに必要不可欠なものに、「イベントスクリプトの処理系」というものがあります。ネットでもこうした「イベントスクリプトの処理系」について考える人が少なくないのも、こうした必要性の表われと言えるでしょう。 しかし、こうした処理系は、それぞれのプログラマが独自の文法でプロジェクトごとに作り直しているのが現状です。これが、コードの再利用、ひいては「気楽にゲームを作る」上での大きな障害に

  • 1