ごみ集めのないLISP 2020年5月 第17回関西Lispユーザ会 @zick_minoh 頭の悪い
1.9以降に搭載された正規表現エンジン(oniguruma, onigumo)では (?<name>式)によってマッチした式部分に名前(ここではname)を付けることができ、 それにマッチした内容を後方参照\k<name>で参照でき、 また\g<name>でその式を再帰的に呼び出すことができる これを使えば、括弧のペアを対応させた上でマッチさせることができる。 たとえば次の例ではLispのシングルクォーテーション記法をquote関数の呼び出しに変換する。 regexp = /'(?<paren>\((?:[^()]|\g<paren>)*\))/ replace = '(quote \k<paren>)' # 1段 "'(+ 1 2)".match(regexp) #=> #<MatchData "'(+ 1 2)" paren:"(+ 1 2)"> "'(+ 1 2)".gsub(reg
私には、Emacs Lisp によるウェブアプリケーション開発シーンを盛り上げていきたいという熱い想いがあります。 最近、「次に来る大物Web言語」と称され Elixir などが注目されている様子が伺えますが、ウェブアプリケーションのサーバーサイド実装において次に来る言語というのであれば、個人的には Emacs Lisp こそを推していきたいと思います。なぜなら Emacs Lisp には、インタプリタでありそして同時にプログラミング環境でもある Emacs というソフトウェアが存在するからです。Emacs と最も親和性が高く、最もプラグインが豊富な言語こそが Emacs Lisp です。これを単なる Emacs の設定やプラグインを記述するための言語に留めておくには惜しいと言えるでしょう。 残念ながら現状 Emacs Lisp でのウェブアプリケーション開発は全くといって注目されていない
9/27(日)に開催されたISUCON5のオンライン予選に参加しました。 僕はアプリケーション側の改善、他の二人はインフラ寄りの対応をするように事前に役割分担をしていました。 “ISUCON”とは ISUCONは「Iikanjini Speed Up Contest」の略で、LINE株式会社 (昔はLivedoor) が主催する、アプリケーションやインフラのパフォーマンスチューニングを行ってそのスコアを競うイベントです。2〜3人のチームを作って参加します。 優勝賞金100万円!今年もやります ISUCON5 開催と日程のお知らせ #isucon : ISUCON公式Blog この週末の2日間にオンライン予選が行われました。 チームビルディング ISUCONというイベント自体は知っていたのですが、どうも自分には縁遠いものだと思っていました。まさか参加することになろうとは。 というのも、ISU
Cで書くコードの方がCommon Lispで書くより速いって人がいたら、それは彼のCの技量が高すぎるってことだね。 “If you can't outperform C in CL, you're too good at C.” — Eric Naggum 最近、Common Lispの非同期Webサーバ「Wookie」を高速化する過程で、ボトルネックになっていたHTTPリクエストのパース部分を高速に処理するライブラリを書きました。 fast-http - A fast HTTP request/response parser for Common Lisp 既存のライブラリ「http-parse」よりも約10倍速く、Cのライブラリ「http-parser」より5%ほど高速です。 追記 (2014/10/26): 最適化をやり直し、現在は「http-parse」よりも約27倍速く、Cの「h
「O/Rマッパー」や「ORM」と聞くだけで顔をしかめる人もいらっしゃいます。たぶん過去にひどい目にあったんでしょうね。その大きな理由の一つがパフォーマンスでしょう。 一昨年のYAPC::Asiaに参加したとき、ORMは使うなという話を4回くらい聞いたのが印象的でした。DBのデータはハッシュで返すか、DBIをそのまま使うほうが良いと。弊社でもパフォーマンス上の問題をわかりづらくしてしまうことから、ORMを使用しないプロジェクトがいくつかあります。 まあ、そりゃDBI使うほうが高速に動くとは思います。 しかし、僕が使っているのは実用的な言語であるCommon Lispです。実行効率と抽象化がとても得意な言語です。さらに優れたオブジェクトシステムであるCLOSも仕様に含まれています。 そこで、既存のO/RマッパーにCommon Lispらしさを加えてみるとどうだろう。 そう思って作ってみたのが、
コンスセルは 数珠つなぎにすることができます。 > (cons 3 (cons 1 2)) (3 1 . 2) (3 1 . 2) というのは (3 . (1 . 2)) の省略形です。 このとき、メモリーは図2の様になっています。 また、違う種類のデータを組み合わせることもできますし、入れ子にすることもできます。 > (cons #\a (cons 3 "hello")) (#\a 3 . "hello") > (cons (cons 0 1) (cons 2 3)) ((0 . 1) 2 . 3) このようなことができるのは、Scheme が全てのデータをアドレスで管理しているからです。 ちなみに #\c は c という文字を表します。 例えば #\a は a という文字を表します。 2.2. リスト 一番最後のコンスセルの cdr 部が '() になった一連のコンスセルをリストと呼び
プログラミングをより深く理解するための近道は、プログラミング言語を実装してみること。SchemeのサブセットをRubyで実装していくことで、プログラムはどう実行されるのか、その基本がはっきり分かります。 ※本書はCC BYにより配布されています。上記の「買い物かごへ」ボタンからは有償で購入できます。無料で入手したい場合は、下記リンクよりダウンロードしてください。なお、有償版も無償版も内容は同一です。 EPUB版PDF版内容紹介プログラムは書けても、その基礎となっている計算機科学(コンピュータサイエンス) の理解があやふやな人を、著者は多く見てきました。プログラミングに自信があるという人が、もう一歩先に進める道を示したいというのが、この文書を書き始めた動機です。 この文書を読むことで次の効果が得られることを期待しています。 プログラミング言語とは何かを深く理解することで、プログラミングのレベ
※追記 (04/12 19:30): うごメモはてな情報取得APIの公開を終了しました ※追記 (05/07 20:00): 再提供に伴って最新のAPI情報に合わせて修正しました こんにちは、id:nitro_idiot です。 本日、うごメモはてなの様々な情報を取得することができるAPIを公開しました。 提供は2013年5月31日のうごメモはてなのサービス終了をもって終了しますが、ユーザ様により自由な形でのデータ保管ができるよう開発・公開しました。 このAPIでは以下の情報を取得することができます。 作品情報 作品の作者や親作品情報、スターなどの評価の数や、FLV・アニメーションGIFのURIなどを取得できます。 ユーザの作品 ユーザが投稿したすべての作品の情報を取得できます。 お気に入り作者 ユーザがお気に入りしているユーザ情報を取得できます。 ファン あるユーザをお気に入りしているユ
この中でカール・ヒューイットが設計した規則ベースの言語 Planner はあまりに複雑な機構を持っていたため当初設計された全機能の実装は困難であり[注釈 9]、サスマン等はそれをサブセット言語の Micro-Planner として実現し、さらには、 Planner の流れを汲んだ独自言語として Conniver を作成した。 同じくカール・ヒューイットが設計したアクタ言語 Plasma (Planner-73) も複雑な機構を持っていたため、MacLisp による実装が存在したものの、その動作の仕組みを理解するのは困難であった。サスマン及びガイ・スティール・ジュニアは Plasma を理解するために、不要な機能を省いた LISP 構文を持つ小さな Plasma を設計した。 上記の Plasma からその小さな Plasma の設計に至る過程は Planner から Micro-Plann
Peter Norvig / 青木靖 訳 このページには2つの目的がある。コンピュータ言語の実装について一般的な記述をすることと、Lispの方言であるSchemeのサブセットをPythonで実装する具体的な方法を示すことである。私はこのインタプリタをLispy (lis.py)と呼ぶ。何年か前に私はJavaとCommon LispでSchemeインタプリタを書く方法を示した。今回の目標は、アラン・ケイが「ソフトウェアのマクスウェル方程式」と呼んだところの簡潔さと取っつきやすさを可能な限り実現するということだ。 SchemeのサブセットLispy の構文と意味論 コンピュータ言語の多くは様々な構文的な決まり(キーワード、中置演算子、カッコ、演算子優先順、ドット記法、セミコロンなど)を持っているが、Lisp族言語の1つとして、Schemeの構文はすべてカッコ付きの前置記法であるリストを基本とし
LISPの真実を読んでたら最後に出てきたので、かなり古い記事だけれども、Eric Kidd氏のWhy Ruby is an acceptable LISPを訳してみました。まつもとさんによる反応もあり、そのエントリの中で原文はほぼ要約されています。 一年前、私はRubyに注目してはいたものの、それを無視することにした。RubyはPythonほどポピュラーではないし、LISPほど強力というわけでもない。なのに何故気にかけなければならないというのか。 もちろん、これらの評価基準は考えなおすこともできる。もしRubyがLISPよりもポピュラーで、Pythonよりも強力だったらどうなるだろうか?*1 それはRubyを興味深いものにするに足るのではないか? この疑問に答える前に、LISPを強力たらしめているものは何なのかを定義しておくべきだろう。Paul GrahamはLISPの美徳について雄弁に語
John Fremlin 氏は小規模ダイナミックコンテンツ用に設計された自称「世界最速」なウェブサーバ teepeedee2をリリースした (本家 /. の記事、John Fremlin's blog の記事より) 。 このサーバは全て LISP で書かれている。Fremlin 氏は昨年 11 月の Tokyo Linux Users Groupでこのプロジェクトを発表しており (pdf)、/.Jer の中には既にご存知の方もいるかもしれない。そこで彼はベンチマーク結果から「関数型プログラミング言語が C に勝ることができる」ことを示したという。 Github の teepeedee2 プロジェクトサイトはこちら。
今年の春頃からトリプルディスプレイで仕事しているbokkoです。なんだか同僚の視線が気になりますが、あえて空気を読まないことにしています。 前に「EmacsLispを自分で拡張する際のTips」という記事を書きましたが、今回はその続きです。 EmacsLispは難しい? EmacsLisp(以下、elisp)は難しいという意見をたまに耳にしますが、elisp自体はそれほど難しいものではありません。ただ、関数名がバラバラでややこしかったり、マニュアルが巨大でどこを見ていいのかわからず、目的のことをするための関数が見つからない、といったようにユーザが難しいと感じるのはelispという言語そのものではなく、環境(OS、ウインドウ、バッファなど)とのインタフェースにあるため、結果的にEmacsLispは難しいと感じてしまうことが多いようです。 実際、elispでプログラミングしていて感じるのはウ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く