14

私はスキームを学んでおり、今までガイルを使用してきました。私は関数型プログラミング言語を独学する方法として学んでいるだけですが、研究を強化するためにある種のオープンソース プロジェクトを公開したいと思っています。だからおそらく何かウェビー。

これらのさまざまな実装があり、言語自体 (R5RS) のコアを超える実際の標準がないため、スキームコードを公開することは非常に簡単ではないことが明らかになりつつあります。たとえば、ほぼ確実に、ディスク上および TCP ソケット上で基本的な IO を実行する必要があります。また、スキャンや正規表現などの文字列操作も必要になります。ドキュメントで。Scheme は実用的な言語というよりも「概念」のようです...これは公正な評価ですか? オープンソース プロジェクトで使用するのに適した関数型プログラミング言語を学びたいのであれば、おそらく Haskell のようなものに目を向けるべきでしょうか?

実際、オープンソース プロジェクトを公開したい場合、さまざまなスキームの実装がもたらす苦痛はどれほどのものでしょうか? さまざまな主流の実装 (Chicken、guile、MIT、DrRacket) での文字列操作などの基本的なことのために、5 つの異なる関数を維持する必要はありません。独自のスキームにのみ存在するライブラリ関数と密結合するのではなく、相互実装互換性のために実際にスキームを作成する人は何人いますか?

http://www.ccs.neu.edu/home/dorai/scmxlate/scheme-boston/talk.htmlを読みましたが、自信がありません ;)

編集 | 「標準」を「共通」に再定義しましょう。

4

4 に答える 4

16

私は、Scheme では、移植性は愚か者の用事であると信じています。なぜなら、Scheme の実装は類似しているというよりは異なっており、他の実装がエミュレートしようとする単一の実装がないからです (たとえば、Python や Ruby とは異なります)。

したがって、Scheme の移植性は、「OpenGL と DirectX の間の共通のサブセットにあるため」、ゲームを作成するためにソフトウェア レンダリングを使用することに似ています。言い換えれば、これは最小公分母であり、実行できますが、実装が提供する多くの機能にアクセスできなくなります。

このため、SRFI は一般に移植性のある参照実装 (実用的な場合) を持っていますが、最適に機能するためには、Scheme の高品質な実装では実装固有の機能を使用するようにライブラリを調整する必要があるという注意事項が付随しているものもあります。

  • 代表的な例はcase-lambda( SRFI 16 ) です。case-lambdaそれは移植可能に実装でき、参照実装はそれを示していますが、「ユーザー」コードで関数ディスパッチを実装する必要があるため、組み込みの に比べて明らかに最適ではありません。
  • 別の例はSRFI 41stream-constantからのものです。参照実装では、移植性のために循環リストの O(n) シミュレーションを使用しますが、適切な実装では、その関数を実際の循環リストを使用するように適応させて、O(1) にする必要があります。†</sup>

リストは続きます。Scheme の便利なものの多くは移植可能ではありません — SRFI はより多くの機能を移植可能にするのに役立ちますが、SRFI がすべてをカバーできる方法はありません。有用な作業を効率的に実行したい場合は、移植性のない機能を使用する必要がある可能性が非常に高くなります。あなたにできる最善の方法は、SRFI でまだカバーされていない機能をカプセル化するファサードを作成することだと思います。

†</sup> 実際には、循環リストをまったく使用せずに O(1) 方式で実装する方法があります。stream-constant勝利のためのポータブルで高速！

于 2012-06-16T19:01:37.487 に答える
10

実装言語としてSchemeを使ったブログを書いています。私は、Scheme の特定の実装のユーザーを疎外したくないので、R5RS と構文ケース マクロと私の標準プレリュードに基づく、Scheme の制限された方言を書きます。. 私が書いている種類のアルゴリズム プログラムに対して過度に制限的であるとは思いませんが、あなたのニーズは異なるかもしれません。ブログのさまざまな演習を見ると、私が独自の正規表現マッチャーを作成したこと、かなりの量の文字列操作を行ったこと、インターネットからファイルを取得したことがわかります。 wget (私は Chez スキームを使用します。他のものを使用する場合、ユーザーは独自の移植性のないシェル メカニズムを提供する必要があります); ANSI 端末シーケンスを作成することで、限られたグラフィックス作業を行ったこともあります。

Jens には少しだけ反対します。後で移植するよりも、最初から移植性を組み込む方が簡単だと思います。私は以前はそのように考えていませんでしたが、過去 3 年間の経験から、それが有効であることを示しています。

于 2012-06-16T13:16:37.323 に答える
10

難しい質問。

ほとんどの人は実用的であることを決定します。実装間の移植性が重要な場合は、プログラムの大部分を標準のスキームで記述し、非標準の部分を (小さい) ライブラリに分離します。これを正確に行う方法については、さまざまなアプローチがありました。最近の取り組みの 1 つが SnowFort です。

http://snow.iro.umontreal.ca/

古い取り組みは SLIB です。

http://people.csail.mit.edu/jaffer/SLIB

正規表現とレクサー/パーサーのライブラリを探したり、尋ねたりすると、すぐにいくつかを見つけることができます。

R5RS の哲学は、すべての実装者が同意する言語機能のみを含めることであるため、標準は小規模ですが、非常に安定しています。

ただし、「現実世界」のプログラミングでは、R5RS は最適ではない可能性があります。したがって、R6RS (および R7RS?) には、より多くの「現実世界」のライブラリが含まれています。

とはいえ、それが正しいと思われるために移植性のみが必要な場合は、本当に努力したい場合は慎重に再検討してください。私は自分が最もよく知っている実装でプログラムを書くだけです。その後、必要に応じて移植します。多くの場合、これは予想よりも簡単です。

于 2012-06-16T12:06:57.297 に答える
6

最新の Scheme 実装自体はかなり移植可能であることは指摘しておく価値があります。適切なスキームを持ち込むだけで、プログラム全体を新しい環境に移植できることがよくあります。ただし、これはライブラリ プログラマにはあまり役に立ちません。そこで、最新の Scheme 定義である R7RS-small の出番です。まだ広く実装されていませんが、R5RS よりも大きな共通コアを提供します。

于 2014-01-10T03:27:10.977 に答える