0

これは、ハッシュテーブルをエクスポートするライブラリです。ライブラリには、ハッシュテーブルに入力する式も含まれています。

(library (abc-1)

  (export tbl)

  (import (rnrs))

  (define tbl (make-eq-hashtable))

  (hashtable-set! tbl 'a 10)
  (hashtable-set! tbl 'b 20)
  (hashtable-set! tbl 'c 30))

ハッシュテーブルにデータを入力するために使用できるプロシージャをエクスポートするライブラリの別のバージョンを次に示します。

(library (abc-2)

  (export tbl init-tbl)

  (import (rnrs))

  (define tbl (make-eq-hashtable))

  (define (init-tbl)
    (hashtable-set! tbl 'a 10)
    (hashtable-set! tbl 'b 20)
    (hashtable-set! tbl 'c 30)))

最初のアプローチを取るのは悪い形と見なされますか? つまり、任意の式も実行するライブラリが必要ですか? このアプローチには欠点がありますか?

関連する問題... ライブラリでは、定義の後に非定義式が発生する必要があります。この制約を回避するために、次のマクロを使用しています。

  (define-syntax no-op-def
    (syntax-rules ()
      ((_ expr ...)
       (define no-op
         (begin
           expr
           ...)))))

例えば：

(define t0 (make-eq-hashtable))

(no-op-def
  (hashtable-set! t0 'a 10))

(define t1 (make-eq-hashtable))

(no-op-def
  (hashtable-set! t1 'b 20))

繰り返しますが、この回避策を使用して式と定義を散在させることには欠点がありますか?

4

1 に答える 1

2

これらのどちらにも大きな問題はありません。たぶん、それが決して使用されないバインディングであることを明確にするためにに変更no-opします。dummy

トップレベルの副作用式で考えられる唯一の問題は、一部の実装では、必要と思われるときに実行されない可能性があることです。R6RSでは、「暗黙的なフェーズ」が可能です。つまり、ライブラリをインポートするだけで、識別子が使用されている場所に応じて、言語がライブラリを正しいフェーズに移行します。したがって、このような実装（Ikarusなど）では、ライブラリをインポートするだけでその識別子を使用しない場合、ライブラリはインスタンス化されません。したがって、インポート時に一部のものを印刷するために使用されるだけのライブラリはインスタンス化されません。したがって、バインディングもエクスポートしておらず、インポート側がそのバインディングについてどこかに言及している場合を除きます。

しかし、それはあなたの場合には問題にはなりません。

于 2011-06-30T17:31:59.960 に答える