タグ

schemeに関するkobapanのブックマーク (10)

  • CPS – Good Book

    CPS形式への変換による末尾最適化 通常,Cなどの言語では再帰呼び出しの回数が多すぎるとstackのオーバーフローを起こす. なぜなら,関数呼び出しの度にstackに積まれる情報は,関数が戻り値を持って制御を呼び出し元に返すときまで解放されないからだ. 同様の事は深い関数呼び出しでも起こる. schemeはその仕様上,再帰によってループを表現するのだが, ループの回数が増える事は再帰呼び出しの深さが増していくのと等価になるため, ループ呼び出し回数がstackの大きさによって左右される事になる. そのために,Schemeでは末尾再帰の最適化が行われる. 以下のような式は適切に最適化されること仕様としてR5RSに盛り込まれている事は良く知られている. (define fact (lambda (n a) (define fact-iter (lambda (n a) (if (

    kobapan
    kobapan 2010/01/29
    末尾最適化
  • Scheme コードバトンまとめページ - higepon blog

    バトン参加表明中 emasaka さん[done] leque さん[done] Kazuhiro MUSASHI (kazu634)さん[done] naoya_t さん @nkoguro さん(2月ならOK) Scheme id:higepon: 第1回 Scheme コードバトンのお知らせ gist: 273431 - GitHub id:yad-EL さん: Schemeコードバトンに参加しました - ヤドカリデンキ商会(第一倉庫) gist: 273551 - GitHub さっそくバトンの醍醐味であるダイナミックな書き換えが発揮され Gauche 向けに書き換えられました。second -> cadr ですが個人的には first, second が好き。 Gauche なら (use srfi-1) 。入出力のバッファリングは確かにはまるポイントかも。call/cc はわざと

    Scheme コードバトンまとめページ - higepon blog
    kobapan
    kobapan 2010/01/12
    達人コード
  • 『「Lisp脳」の謎に迫る』の舞台裏

    ドット対(1 . 2)は対であるがリストではない 空リストは対ではないがリストである 空でないリストは対でありかつリストである この事実から「リストはまた対である」を以下の通りに修正する必要があります。 空リストは対ではない 空でないリストは対である なぜ「配列」でなく対で並びを表現するのか? SchemeをはじめとするLisp言語では、なぜ「配列」でなく対で並びを表現するのでしょうか? 対で並びを表現すれば、いくらでも入れ子構造にすることができる 入れ子構造になった対は再帰的に処理することができる あらゆるデータ構造を(入れ子構造になった)対で表現できる 入れ子構造になった対でプログラムコードも表現できる これまで見てきたように、対はcons手続きでいくらでも入れ子構造にすることができます。また、入れ子構造になった対にcar、cdrを適用すればどんな要素も取り出すことができます。これは、

    kobapan
    kobapan 2010/01/06
    『「Lisp脳」の謎に迫る』の舞台裏
  • SICP Lite #4 - yukichanko's diary

    今回で4回目。ようやく1章の終わりが見えてきた感じですが、何となく大事なことが置いてけぼりの感じもしています。 とりあえず、SICPを読む上で、最も難関と言われる数学の話。第1章の主題は、単純な手続きを抽象化する方法を身につけて、汎用な関数を作り上げる、と言うものなので、数学に捕われていると主題を忘れてしまいます。しかし、悲しいことに、ある程度数学を抑えとかないと後半の高階関数による汎用化のところはポイントが抑えられないのも事実。 と言うことで、ごくごく簡単にSICPの中に出てきている数値解析の技法の絵を描いてみました(昨日も書けば良かったんだけど、ホワイトボードのところに行きつけなくて)。 Binary Search 言わずと知れた2分探索。別名、挟み撃ち法。直感で分かりやすいんだけど、収束性が良くないので、非線形方程式の解法に使われることはほとんどない。 Fixed Point 不動点

    SICP Lite #4 - yukichanko's diary
  • 横着プログラミング 第10回: scmail: Scheme によるメールフィルタ

    最終更新日: 2004-03-11 (公開日: 2003-02-18) Unix Magazine 誌に 2002年1月号から 2003年2月号にかけて連載し ていた記事の元の原稿です。 プログラミングについての考え方に影響を与えないような言語は 知る価値がない -- Alan Perlis *1 Lisp というプログラミング言語がある。プログラミング言語につ いて語られるとき、Lispほど物議を醸す言語はないように思う。 Lispは 1950年代後半に生まれた、高級言語としては最古に近い言 語である。しかし、一部のプログラマの間ではいまだに強い影響力 を持っている。筋金入りの Lisper (Lispプログラマ) である Paul Graham 氏が昨年に発表したエッセイ「普通のやつらの上を行け」 *2 では、Java, Python, Perl, C などの他の言語と比べて Lisp

  • Erlang or Gambit-C/Termite? A practitioner's perspective

    Regularly, I need to prototype a new idea that could lead to the development of a new project or product at work. Each time, I have to ask m...

  • R5RS (Revised^5 Report on Algorithmic Language Scheme) 日本語訳

    back これは Suzuki Hisao さん (suzuki@otsl.oki.co.jp) による、 Scheme の仕様書 R5RS (Revised^5 Report on Algorithmic Language Scheme) の日語訳です。新山が訳したわけではありません。 1999年 3月に fj.comp.lang.lisp に投稿されたものを、新山が コンパイル、変換しました。 R5RS の日語訳としては、犬飼 大さんによる日語訳が多く出回っていますが、 新山は Suzuki さんによる版のほうが読みやすいと思います。 [Gzipped tar, 97k] r5rs-ja.tar.gz Suzuki さんによって最初に fj に投稿された TeX ソースのアーカイブ。 以下のファイルはすべてここから生成しました。 [PDF, 430k] r5rs-ja.pdf P

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

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

  • Lispへの憧憬

    1960 年生まれ,独身フリー・プログラマの生態とは? 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から,現在に至るまでの生活を振り返って,週1回のペースで公開していく予定です。プログラミングに興味がある人もない人も,フリー・プログラマを目指している人もそうでない人も,“華麗”とはほど遠い,フリー・プログラマの生活をちょっと覗いてみませんか。 ※ 記事は執筆時の情報に基づいており,現在では異なる場合があります。 Lispという言語がある。プログラミング歴が長い人なら,カッコをたくさん書く言語ということぐらいはご存じではないかと思う。1980年代にエキスパート・システムと呼ばれる技術がブームになり,その手のプロジェクトで利用されたため,仕事で使ったことがある人もいるかもしれない。 何を隠そう,私もその一人である。し

    Lispへの憧憬
  • 11. 継続 | Schemeへの道

    継続(continuation)とは,式を評価している途中のある時点で,『いま得られた 値を使って,この後は何を計算するのか』を表すものである.たとえば,Scheme の関数呼びだしの式を評価する際には,まず関数とその引数を評価して,その 後で関数に引数を適用する. ==> (+ (* 1 2) (* 3 4)) ;; ==> (+ 2 12) ;; ==> 14 14 この式の場合,まず「+」,「(* 1 2)」,「(* 3 4)」を評 価したのち,「(+ 2 12)」を評価する. 各部分式の評価が左から右へ進むものとすると, たとえば,「(* 3 4)」を評価した後にするべき計算,つまり継続は, 『いま得られた値に2を加える』 である.この式の評価を完了するためには, Schemeのシステムは,この継続を知っていなければならない. 継続は,「何を評価して,その値によって次には何を行う」

  • 1