CLでpythonみたいなライブラリ群の開発
Ryohei Ueda
表題のように, CommonLispでpythonが標準ライブラリとして提供するものを
サポートするようなライブラリ群を開発してみたらどうだろうか?と思ってます.
というのも, CLはライブラリが少ないというのがあまり利用されない大きな原因に
なっていると思うからです.
そこで, まず, pythonの標準ライブラリあたりをターゲットにライブラリを充実させたら
よいんじゃないかなと思っています.
まだ, どうやって開発を進めていくかとか何も考えていませんが,
自分も開発に参加したい!というひとはreplyもらえるとうれしいです.
githubあたりでレポジトリを作って, どっかにMLをつくって...という流れに
なるかと思います.
ではでは
-- ryohei
深町英太郎 (E. Fukamachi)
深町です。
Shibuya.lisp発でこういう動きがあるのはとてもいいですね。
僕も開発に参加します
--
深町英太郎 (E. Fukamachi)
2010/11/28 Ryohei Ueda <gara...@gmail.com>:
sakura lambda
あまり力になれるのか不安ですが参加したいです。
Pythonと同レベルだとドキュメントの整備が一番大変かもしれませんね。
SANO Masatoshi
土曜はありがとうございました。
#動画を準備してますが、難しいっす…
Pythonの標準ライブラリを軽くぐぐって、
すごいざっくりした話であることがやっとこわかってきたところです。tk? locale?
やれる所があったら協力したいのですが、これを全部舵取ってやりとげるぜ!というやる気は個人的には無いな…という
結論がでつつ…
とりあえずbikeshed discussion的には
個々人Common Lispにライブラリが少ないというのはいったいどういうことを指しているのか
ということを表明していった方が協力を求める人としてもその人が見ている方向が
見えて良いのではないかと思いました。
個人的にはaclのexcl.osiのポータブルな実装が他の処理系向けに欲しいなーと思っている程度の人です。
では。
2010/11/28 Ryohei Ueda <gara...@gmail.com>:
--
佐野匡俊(SANO Masatoshi)
snm...@gmail.com
aka
Ryohei Ueda
> とりあえずbikeshed discussion的には
> 個々人Common Lispにライブラリが少ないというのはいったいどういうことを指しているのか
> ということを表明していった方が協力を求める人としてもその人が見ている方向が
> 見えて良いのではないかと思いました。
そうですね, どこから始めたらいいのか?という話題はあると思います.
このプロジェクトでは, とにかく広く使われているpythonに標準でついてくるライブラリは
素晴らしい(はずだ), という前提です.
個々人がほしいものは違うと思うのですが, これからCLを書いてみようという人が,
「pythonだったら数行でできるのに, CLじゃこんなんもできないのかよ」と思ってしまっている
というのが現状じゃないかと思います.
で, それらをサポートするものを提供すれば, もっとLisp界隈は活発になるんじゃないかと思ってます.
Peter NorvigのLispプログラマのためのPython入門でLisp <-> Pythonの表がありますが,
それをさらに広げて, pythonの標準ライブラリまで作ってしまおうというわけです.
http://www.unixuser.org/~euske/doc/python/python-lisp-j.html
> ちなみに、CLtL3とは違う方向、同じ方向？
違うかと思います
ただ, このプロジェクトで必要な処理系間のコンパチビリティはでてくるはずで,
CLtL3へのフィードバックは出来るかと思います
-- ryohei
2010/11/29 aka <aka.c...@gmail.com>:
aka
お返事どうもです。
なるほど、Pythonの標準クラスライブラリというか、
標準クラスライブラリが提供する機能を*そのまま*CLに
もってくるということなんですね！
ちょっと考えてみます。
ありがとうございました。
Kiyoshi Mizumaru
> 標準クラスライブラリが提供する機能を*そのまま*CLに
> もってくるということなんですね！
それって何てCLPython
http://common-lisp.net/project/clpython/
目指すところが違うんだと思いますけど、
ぼくはまだいまひとつ明確に理解できてない感じ。
CLはライブラリが不十分、っていう文句を言わせない、がゴール？
2010/11/29 aka <aka.c...@gmail.com>:
Ryohei Ueda
> http://common-lisp.net/project/clpython/
pythonそのものを実装しようというのではないです.
cl-pythonとはかぶる部分も多いとおもいますが,
pythonで
import logger
logger = logging.getLogger("root")
logger.debug("logger=root : debug message")
とかけるなら,
CLでも
(require :logger)
(defvar *logger* (logger:get-logger "root"))
(logger:debug *logger* "logger=root: debug message")
とかけるようなものを用意していこうというイメージです
> CLはライブラリが不十分、っていう文句を言わせない、がゴール？
はい, まさにそうです
そのときにどの程度ライブラリを作ればいいのかの指針がないので,
とりあえずpythonに標準で含まれてるものから埋めていこうという作戦です
-- ryohei
2010/11/29 Kiyoshi Mizumaru <kiyoshi....@gmail.com>:
aka
言語仕様以外の部分の障壁を低くする、というあたりがツボ
ではないかと。
Norvigのを例に引いているので、CL上にPythonインタプリタを
実装するということではないと理解してます。
aka
スズキタカユキ
kurohuku
役にたてるかはわかりませんが，ぜひ参加させてください．
Naoto Yokoyama
USER> (asdf:operate 'asdf:load-op 'log4cl) USER> (in-package :log4cl) LOG4CL> (setf new-logger (make-instance 'logger)) LOG4CL> (setf app-console (make-instance 'console-appender)) LOG4CL> (add-appender new-logger app-console) LOG4CL> (log-debug new-logger " a log message ") logger : [ERROR] a log message $>more /tmp/log-test.log logger : [ERROR] a log message
とできる事が分かります．
しかし，Common Lisp には上に述べた logger のようなものを含む
所謂「標準」ライブラリというものが存在しないため，CL を使って
役に立つコードを初めて書こうとしたとき面食らってしまうかもしれません．
つまり，ここでの目標は，安心して CL を使えるように，
python で提供されているような一定した品質のライブラリ群を CL においても
「標準」ライブラリのように提供するといった理解でよろしいでしょうか？
Ryohei Ueda
>
> python で提供されているような一定した品質のライブラリ群を CL においても
>
> 「標準」ライブラリのように提供するといった理解でよろしいでしょうか？
「標準」だぜ!と面と向かって主張するかは別ですが...
ライブラリの品質というのは個人的に以下の3つに分けられると思います.
1. 速度
2. 安定性
3. API設計の良さ
1の速度については, 処理系にも依存しますし, めんどうな議論になりそうなのでおいておきますが...
# 個人的にはかなり重要だとおもっていますし, CLなので主張しどころだとも思いますが.
2, 3についてが重要だと思います.
2の安定性については, 安定なものを「目指すべきで, 目指していく」としか言えませんが,
3の部分は議論の結論が出ないものだと思ってます.
APIが良いか悪いかというのは, 十分な数のユーザがいて, その大多数が賛成しているというのが
何よりも大きな根拠になると考えてます.
で, pythonだったらユーザも多いし, それをそのまま参考にすれば最低限のコンセンサスが
得られるのではないかという狙いです.
# もちろん, python使いの人たちを取り込みやすいように, という狙いもあります
log4clがlog4jを参考にしてその機能の根拠にしているのと同じですね.
もちろん, "python的"なloggerの実装で, 可能であればlog4clを利用しても良いと思ってます.
-- ryohei
2010/11/29 Naoto Yokoyama <built...@gmail.com>:
Naoto Yokoyama
>とりあえずpythonに標準で含まれてるものから埋めていこうという作戦です
Ryohei Ueda
みなさん返信ありがとうございます
# 反応が多くてビビってたりしますが
どうやって開発をすすめるかとか, もうちょっと具体的な議論をすすめるために,
MLを設置したいとおもいます.
そのためにはプロジェクトの名前を決める必要があります.
なにか良い案はありますか?
勢いを殺さないために, 今日中に決めたいと思います.
言いだしっぺとして, 一つ提案すると,
plantというのはどうでしょうか?
ヘビでwikipedia検索 http://ja.wikipedia.org/wiki/%E3%83%98%E3%83%93
-> "草を打って蛇を驚かす"ということわざ
-> 草 = plant
PLANT = Pythonic Lisps out of Anarchic Toolbox
(辞書で目についた単語を並べてみました)
-- ryohei
2010/11/30 Naoto Yokoyama <built...@gmail.com>:
深町英太郎 (E. Fukamachi)
;; Twitterでつぶやきましたがwhipもどうかと思う
;; 何か思いついたらpostします
--
深町英太郎 (E. Fukamachi)
2010/11/30 Ryohei Ueda <gara...@gmail.com>:
木脇 太一
2009年度下期の未踏ユースで
Common Lispを使って
開発していた木脇と言います．
現段階でどこまで貢献できるかなどは
全く分からないのですが，
興味はあるのでMLへは
是非登録をお願いします．
何かのお役に立てれば
と思います．
よろしくお願いします．
木脇太一
Naoto Yokoyama
Ryohei Ueda
他に対案はありますか?
Ryohei Ueda
では, CLAPにしようとおもいます
佐野さん
お手数ですが, MLの設置をお願いできますか?
-- ryohei
2010/12/1 Ryohei Ueda <gara...@gmail.com>:
higepon
ML ですが基本オープンで良いのならば
Google groups など外部のものでも良いのではないでしょうか。
管理の手間が減り、永続性が高まるような気がします。
2010/12/1 Ryohei Ueda <gara...@gmail.com>:
Ryohei Ueda
> ML ですが基本オープンで良いのならば
> Google groups など外部のものでも良いのではないでしょうか。
>
> 管理の手間が減り、永続性が高まるような気がします。
たしかに, 管理の手間がかかってしまうのはよくないですね...
では, google groupsにMLを作成しようかとおもいます
>> 佐野さん
>> お手数ですが, MLの設置をお願いできますか?
なんか方針が行ったり来たりして, 申し訳ありません
-- ryohei
2010/12/1 higepon <hig...@gmail.com>:
SANO Masatoshi
えーとMLは作ったのと前に送ったメールで
garaemonさんには通じるはずなので、
使うとかの判断はgaraemonさんにおまかせします。
--
佐野匡俊(SANO Masatoshi)
snm...@gmail.com
Ryohei Ueda
さっそくgroupを作成しました
http://groups.google.com/group/clap-users
開発に参加していただける方, 開発するかは分からないけど興味のある方,
どんどん登録してください
今後の議論はclap-usersの方で進めたいと思います
ある程度集まったら議題をポストしていきます
MLでは, すごいシンプルなCLの質問とかもあっても良いと思っています
# 逆引きCLにフィードバックできれば素晴らしい
このようなプロジェクトの議論の場を提供してくれたshibuya.lispに感謝!
Ryohei Ueda
> garaemonさんには通じるはずなので、
> 使うとかの判断はgaraemonさんにおまかせします。
了解です
また何かあったら相談させていただきます
色々とありがとうございます
-- ryohei
2010/12/1 SANO Masatoshi <snm...@gmail.com>: