Schemeの新仕様「R6RS」成立 27
ストーリー by mhatta
紆余曲折 部門より
紆余曲折 部門より
WikipediaのSchemeの項目の更新で知ったのですが、 長らく策定作業中だったSchemeの新仕様、R6RSが、この9月ついに成立したそうです。Wikipediaによれば、
とのこと。 Schemeとはプログラミング言語でLISPの方言の1つ、人気はいまいちぱっとしませんが通好みの言語で、 タレコミ子のようなwannabeeにはあこがれの対象です。 今回の新仕様の意義などについてこのストーリーで議論／雑談していただければうれしく思います。2007年9月に新仕様R6RSが成立した。4部構成となり、R5RSに比べおよそ3倍の文章量となった。今までは小さな言語仕様に対してのこだわりが見られたが、Unicodeサポート等の実用的な言語として必要な要素が盛り込まれている点が特徴的である。
About Scheme (スコア:1, 参考になる)
http://cl-www.msi.co.jp/solutions/knowledge/lisp-world/articles/scheme
Schemeはうんこ
Re:About Scheme (スコア:3, 参考になる)
#ここまでテンプレ
チラ見したときに (スコア:1)
わかりやすいけどめんどくさい (スコア:0)
# データプロセッシング的な用途には結構向いてるんじゃないかなー
Re:わかりやすいけどめんどくさい (スコア:0)
Re:わかりやすいけどめんどくさい (スコア:0)
Re:わかりやすいけどめんどくさい (スコア:2, 興味深い)
私は脳内にあるアルゴリズムのイメージをそのまま書けると思います。頭の中の「絵のようなもの」をそのままプログラムにする、と言えば良いのかなぁ？
他の言語だと一端「言語」に変換している感じます。何かC++で書くときと使っている脳が違うような気がするんですよね。
恐らく#1226985の方は「脳内イメージ」→「得意な言語(またはそれに近い脳内言語)」→「Lisp(Scheme)」と頭の中でやっているので構文解析だと言うのでしょうが、「脳内イメージ」→「Lisp(Scheme)」と頭の中で出来るようになると世界が広がると思います。それを楽しめなければ出来るようになるためのトレーニングは「めんどくさい」ですが。
Best regards, でぃーすけ
Re:わかりやすいけどめんどくさい (スコア:0)
Re:わかりやすいけどめんどくさい (スコア:0)
手続きを考えなければならない仕事の方が多い。
だから、Lispは傍流なのだと思う。
たぶん。
Re:わかりやすいけどめんどくさい (スコア:1, おもしろおかしい)
ただ、
実際にプログラムを一杯書いて(書かされて)いて感じたことなんですが、
仕事内容を「手続き」で表現することは、
実は手抜きなんじゃないか？と
感じることが多いです。
ご存知の通り、むき出し(CPUに近い)の「手続き」というものは、
色々と取り扱いが難しい。
一度書いたら後で厳密に検証するのが難しいとか、
「抜け」に対して根本的に無防備だとか。
でも人は、面白い(?)ことに、
ほっとくと(きちんと教育しないと)
実装のみならず設計や分析まで
「手続き」的に書いてしまいがちです。
たぶん手続きで考えるほうが、
楽というか直感的なんだろうと思います。
「やらせたいこと」を順に書くだけですから簡単簡単。
ただ、それだと、
その裏の「やらないとならないこと」の網羅性は
何も保証されない。
要するに、責任を後回しにするために格好のフォーマットなんです。手続き型は。
コーダーのみなさん、
「やりたいこと」ばっかり書いてあって、
「やれるかどうか」
特に「自己矛盾がないかどうか」を
なーんにも考証してなさそうなドキュメントを
寄越されて呆然としたこと、ないですか？
私はずーっとそんなのばかりですよorz
そういう「手続き脳」な人らがドキュメントを書く(のに任せてる)限り、
たぶん状況はよくならないでしょうね。
そして逆にいえば、手続き脳な人らが職を失わないために
明示的にも無意識にも活動し続けてる結果として、
非手続き型が傍流だ、という現状が有るのではないかと愚考します。
＃よーするに陰謀論かぃ
Re:わかりやすいけどめんどくさい (スコア:0)
それはその通りだと思いますが、
>私は脳内にあるアルゴリズムのイメージをそのまま書けると思います。頭の中の「絵のようなもの」をそのままプログラムにする、と言えば良いのかなぁ？
何が「イメージそのまま」なのかすら、人によって違いますから。
イメージが高級(高級言語という意味で)な人も居れば低級な人も居る。
手続き型な人も居れば関数型な人も居る。(そういえばSQLな人も居る。)
無意識のうちに落とすイメージのかたちが、
その人の得意とする言語だ、という感じかと思います。
自分のことを省みても、好きで得意なメイン言語が変遷するにつれて、
頭のなかのイメージ(モデル)自体がバサっと切り替わると
Re:わかりやすいけどめんどくさい (スコア:1)
これは承知した上で申し上げております。私も最初の言語はポケコンのBASICだし、以降、アセンブラ→C→....という順序で言語を修得しております。
以下が重要な点で、私も共感する部分が多いです。
＞無意識のうちに落とすイメージのかたちが、
＞その人の得意とする言語だ、という感じかと思います。
＞ 自分のことを省みても、好きで得意なメイン言語が変遷するにつれて、
＞ 頭のなかのイメージ(モデル)自体がバサっと切り替わるという経験をしてきました。
はい。このイメージのかたちを「手続き型」と「関数型」の二種類としましょう(細かい分類、他の分類は議論の都合上捨象します)。これらのイメージはトレーニング(慣れ)によってどちらも出来るようになる、というのが私の主張です。喩えて言うなら、英語で考えられるくらいに英語が上達しても日本語は忘れない、ということです。ただし、私自身関数型イメージがまがりなりにも出来るようになるまでには大分苦労しました。
また、「手続き型イメージ」→「C/C++の構文」より、「関数型イメージ」→「schemeの構文」の方がより直接的に感じます。(私の場合、Cで書くときのイメージは、Cよりも幾分かアセンブラに近いイメージですし、C++のとき(とくにtemplateを使うとき)は幾分か関数的なイメージも加わります)。私自身経験上「関数型イメージ」力はそんなに強いと言えないですが、それでもそう感じました。
その経験上、Lispで書くときに「C++だとこうだからLispだとこうなる」ではなくて、Lispが自分の最初の言語であるつもりで考えると、「関数型イメージ」力が付くと思うし、世界が広がっていくのではないでしょうか？ということを提案しています。
＃ もどかしいし、そのことを楽しめない限りそれこそ「めんどう」なんですけど。他にはschemeを実装してみるとか(私は今マクロで詰まってます)、schemeを組み込んだアプリを作ってみたりするとかも良い経験かと。
＃それにしてもlink先の記事は楽しいですね。SQLは数独を解くのに不向きであると言うのにも同意です。私自身は、数独のヒューリスティックをC++のtemplateを使いまくりで書いたことがありますが(template<template<typename T>class MT, typename Pos>みたいなのが出てくるくらい)そのときはあまり手続的に考えてないように感じました。
Best regards, でぃーすけ
Re:わかりやすいけどめんどくさい (スコア:0)
関数型言語は開発効率が高い (スコア:0)
スラドには詳しい方々たくさんいらっしゃるのでぜひ聞いてみたい
Re:関数型言語は開発効率が高い (スコア:1, 興味深い)
縁があって関数型言語Ocamlでちょっとしたソフトを作ったことがあります。
使う前は「高階関数？そんなの関数ポインタでもできるじゃん」と思っていたのですが、
匿名関数とかカリー化とかすごく使いやすいです。
関数を変数と同じように気軽に扱えるので、共通部分の処理を関数にまとめやすく
コードの記述量はすごく減る感じがします。
残念ながら僕は根っからの手続き型言語人間なので、副作用のある式とか書きまくりなのですが、
もはや関数型言語なしでは生きれない体になってしまいました。
この関数型言語に対する魅力はRubyに対する魅力に通じる所があるので、
Rubyを魅力的と感じる人にはLispを魅力的に感じるのではないでしょうか。
まあ僕は研究者であり、職業プログラマではないので、
企業で大規模ソフトの開発となると話は別になってくるのでしょう。
その辺の考察は別の人にゆずります。
# Ocamlは純粋な関数型言語じゃないっていうツッコミは入れないで。ぷりーず。
有用な機能は積極的にパクられています (スコア:0)
関数型言語の本質である「破壊的代入がない」っていうのは 普通のプログラミングスタイルとは噛みあわないでしょうね。現実問題として関数型言語の多くは 副作用を許して手続き形っぽく書けるようにもなってます。
とはいっても、いまどきのプログラミング言語は関数型言語の多くが持ってる便利な機能を積極的に取りこんでいます。 スクリプト言語の多くが #1126773 [srad.jp]の人が言ってるlambdaとかカリー化って何かしらの形で実現できるようになっているし、JavaやC#も言語仕様に新しい機能を積極的に加えてます。
つまり「生産性を高める」(と考えられている)機能の多くはモダンな言語でもサポートされているので、 結局プログラマが十分にそれを理解し適切に適用できるかっていうクソ面白くもない結論になってしまいます。
Re:有用な機能は積極的にパクられています (スコア:0)
例えば、手続き型言語が関数型言語の秀でている点をいくら取り込んだとしても、それはあくまでも真似事であって、本質的なところはやはり手続き型言語のまま変わっていないわけですから、、。
具体的に説明せよと言われると困ってしまうのですが。
Re:有用な機能は積極的にパクられています (スコア:0)
なんか性悪説みたいですね。
GaucheとKahua (スコア:0)
新規格がGaucheやKahuaの将来にどのように影響するのでしょうか。
大きな変更があるとすれば、楽しみでもあり、不安でもあります。
Re:GaucheとKahua (スコア:1, 興味深い)
Re:GaucheとKahua (スコア:1, 参考になる)
メーリングリストにshiroさんの見解があります。
当面はそう大きい影響はなさそうですね。
http://lists.osdn.jp/mailman/archives/gauche-devel-jp/2007-July/001744.html
Re:GaucheとKahua (スコア:0)
最終的にはCommonLisp以前の混沌にもどっちゃうのかな？(俺様Lispがいっぱい！)
Re:GaucheとKahua (スコア:2, 参考になる)
各々の実装が特色を追求しつつも、共通のライブラリが書ける何らかの統一基準が必要、という点ではコミュニティは わりと一致してるんですよ。各論で合意できないだけで。R6RSもひとつのdesign decisionとしては有りなんですが、 細部まで検討されたとは言い難く、標準とする域に達していないと私は思います (例えば、formal commentに対して 「提案はreasonableだが検討してる時間が無いので却下」 [r6rs.org]とか)。 個人的にはモジュールシステムだけ標準にしといて、ライブラリはSRFIで練るべきだったと思うのですが (「同じインフラに対して複数の仕様が出てくる可能性がある」という危険は折込み済みで)、残っている R6RS editorsはあまりSRFIにauthorityを認めたくない感じでした。
結局僅差で批准されたわけですが、既存のScheme実装者の多くが否決票を投じているので、「R6RS準拠」なSchemeが どのくらい出てくるかはまだわかりません。(最後まで残ったEditorsがPLT SchemeとChez Schemeの実装者なので このふたつはR6RS compliantになるでしょうが)。ただ、残りのSchemeもR6RSの色々な要素については有用性を認めて いるので、より緩い縛り(SRFIレベル)で互換性を取ってゆこうという動きが立ち上がっています (ERR5RS [cyber-rush.org])。
またこれと協調して、現実に使える共通ライブラリパッケージも作られつつあります (Snowfort [umontreal.ca] )。
おそらく処理系のdiversionという意味では、R6RS以前とさして変わらないか、むしろ改善してゆくのではないかと 楽観しています。
現在、Marc Feeley (Gambitの作者)が各Scheme実装者のR6RSへの対応予定を集計しています。近々c.l.sあたりで 結果が出るのではないかと。
見てないけども (スコア:0)
Re:見てないけども (スコア:0)
R6RS:概要と例 # 例 [practical-scheme.net]
ぶっちゃけ (スコア:0)
得意分野ってあるの？
素で (スコア:0)
こないだ7が出たじゃん。