2

Lisp プログラマーは、他のすべてのデータ型を表すためにリストを使用する傾向があります。

しかし、リストはデータ型の普遍的な表現として適切ではないと聞いたことがあります。

レコードを使用する場合とは対照的に、この方法でリストを使用することの欠点は何ですか?

4

3 に答える 3

5

あなたは「記録」に言及しています。これにより、固定要素の構造体/オブジェクト/複合データを参照していると思います。たとえば、HtDP 構文では次のようになります。

;; a packet is (make-packet destination source text) where destination is a number, 
;; source is a number, and text is a string.

...そして、パケットを複合データ（または「レコード」）の一部としてではなく、長さ3のリストとして表すことの長所と短所について尋ねています。

複合データが適切な場合 (値には特定の役割と名前があり、それらの数が固定されている場合) は、一般に複合データが適しています。それらは、プログラミングの必須要件であるプログラムのエラーを検出するのに役立ちます。

于 2012-01-31T17:26:09.487 に答える
3

欠点は、それが普遍的ではないことです。これはパフォーマンスに関連する場合があります。一定時間のルックアップ (配列、ハッシュ テーブル) が必要な場合があります。これは組織に関連する場合があります。データの場所に名前を付けたい場合があります (ハッシュ テーブル、レコード ... ただし、リストで名前と値のペアを使用できます)。コードを自己文書化するには、作成者側で少し注意が必要です (記録よりも注意が必要です)。場合によっては、間違った場所 (レコード、型付きタプル) に置くことによる間違いを型システムでキャッチしたいことがあります。

ただし、ほとんどの問題は OptimizeLater で対処できます。リストは用途の広い小さなデータ構造です。

于 2012-01-31T16:58:36.943 に答える
2

あなたはPractical Common Lispの第11章でPeter Seibelが取り組んでいることについて話している：

[開始] Lists を使用した Lisp のコレクションの議論。. . リストは Lisp の唯一のコレクション型であるという誤った結論に読者を導くことがよくあります。さらに悪いことに、Lisp のリストは非常に柔軟なデータ構造であるため、他の言語で配列やハッシュ テーブルが使用される多くの用途に使用できます。しかし、リストに注目しすぎるのは間違いです。それらは Lisp コードを Lisp データとして表現するための重要なデータ構造ですが、多くの場合、他のデータ構造の方が適切です。

Common Lisp が提供するすべてのデータ型に慣れると、リストがデータ構造のプロトタイピングに役立つこともわかります。データ構造が正確にどのように使用されるかが明確になると、後でより効率的なものに置き換えられます。

私が見るいくつかの理由は次のとおりです。

  • たとえば、大きなハッシュテーブルは、同等のalistよりも高速にアクセスできます
  • 単一のデータ型のベクトルはよりコンパクトで、アクセスも高速です
  • ベクトルは、インデックスによってより効率的かつ簡単にアクセスできます
  • オブジェクトと構造により、位置ではなく名前でデータにアクセスできます

要するに、手元のタスクに適したデータ型を使用することです。明らかでない場合、2 つの選択肢があります。推測して後で修正するか、今解決するかです。これらのいずれかが正しいアプローチである場合があります。

于 2012-02-02T21:44:33.897 に答える