Factor/FAQ/Factor のライブラリ

Factor には並行性モデル (concurrency model) がありますか？

あります。Factor は、明示的な協調型コルーチン (coroutine) をサポートしています。新しいスレッドはワード in-thread で生成でき、スレッド間での制御の受け渡しには yield ワードを使います。コアとなる thread ボキャブラリには最も基本的なスレッド操作が含まれており、派生的なコルーチン操作は coroutines ボキャブラリにあります。

Factor は複数の OS スレッドをサポートしていますか？

現時点ではノーです。Factor のスレッドモデルの動作は Erlang のそれと似ていますが、Factor にはヒープが 1 つしかなく、ランタイム (仮想マシン) は常に単一の OS スレッドで実行されるという重要な違いがあります。Factor の VM は現在はスレッドセーフではありませんが、将来はスレッドセーフになる予定です。ワードプロパティをはじめとする言語としてのいくつかの特徴から、Factor をスレッドセーフにするには、現時点ではさまざまな課題があります。現在の Factor ではすべてが単一の OS スレッドで実行され、直接的な効率性の利得はないので、Factor のスレッドが有効なのは、待機状態を伴う並列 I/O 操作を実行する場合などです。

ほかの言語にはない Factor の優れた機能にはどんなものがありますか？

まず、ちょっとしたことに役立つ便利な機能として make ワードがあります。このワードを使うと、シーケンスを簡単に構築できます。もう一つ優れた機能として、CLOS (Common Lisp Object System) に関連した、ほかに類例のない Factor のオブジェクトシステムがあります。3 つ目の機能として sequence プロトコルと assoc プロトコルがあり、これらのプロトコルを使うことで連番シーケンスと連想配列をジェネリックに扱うことができます。これは Factor にしかない機能というわけではありませんが、たまたま Factor のライブラリ設計が非常に優れている部分になっています。きわめて興味深いライブラリとして units ライブラリがあります。これは、その後置記法によって、非常に自然に見えるライブラリです。(calendar ライブラリも後置記法がうまく機能します。) このライブラリは、連鎖性の特質を活かして演算の一部を逆に行う inverse という名前のライブラリと組み合わせると威力を発揮します。Slava は、reddit のコメントの中で、これらの優れた特徴について解説しています。

Factor にはどのような外部関数インタフェースがありますか？

Factor の C FFI は、ダイナミックリンクライブラリ (.dll、.so、または .dylib) を実行時にロードし、ユーザーが C によるコードの記述・生成・苦労をしなくてよいようになっています。詳細については、FFI のドキュメントを参照するか、Elie Chaftari の FFI 簡単入門 (brief introduction to the FFI) を読んでください。

Factor には、Objective C FFI を使った cocoa ボキャブラリもあります。

alien を使ったコードが動作しないのですが？

add-library ワードによって適切なダイナミックリンクライブラリがロードされるようになっていることを確認する必要があります。Mac OS X では、目的のライブラリが、Factor バイナリと同じアーキテクチャでコンパイルされていることを確認してください。たとえば、64 ビット版 Factor バイナリを実行している場合は、64 ビット版ライブラリを使用しなければなりません。32 ビットの場合も同様です。

Factor はどのような GUI ライブラリをサポートしていますか？

Factor は、OpenGL と各プラットフォーム用の少量のネイティブコードを使用し、Factor 自身で記述されたクロスプラットフォーム UI ライブラリを使っています。リスナーはこのライブラリを使っています。UI を参照しください。wxWidgets と Gtk に対するバインディングはまだありません。Gtk バインディングは可能ですが、Gtk ではマクロと複雑な構造体を多用しているために、作業はかなり困難になると思われます。Gtk バインディングの実装には、SWIG バインディングが役立つでしょう。wxWidgets バインディングは現時点では不可能です。これは、alien が C++ の名前変換 (name mangling) をサポートしていないためです。

なぜ Factor は Computer Language Shootout に載っていないのですか？

Factor をさらに高速にしてから結果を提出したいと思っています。すでにほとんどの部分では、スクリプト言語よりはるかに拘束ですが、一部の処理についてはまだ調整が必要です。

Factor プログラムをパッケージ化して簡単に実行できるようにするにはどうすればよいですか？

Factor には、Mac OS X の .app パッケージを作成したり、イメージといくつかの .dll をバンドルした Windows と Unix の実行可能ファイルを作成するためのデプロイツールが付属しています。

ボキャブラリをアプリケーションにデプロイし、そのボキャブラリのメインワードを実行するには、次のようなコードを使います。

USE: ui.tools.deploy
"vocab-name" vocab deploy-tool

Factor は Unicode をサポートしていますか？

「Unicode のサポート」という言葉の意味は 1 つではありませんが、今日のプログラミング言語がそれぞれのライブラリでサポートするべきものがいくつかあります。すなわち、UTF-8/UTF-16 入出力、Unicode 照合、Unicode 対応大文字小文字変換操作、正規化、任意の Unicode コードポイントを保持できる文字列、および UI での Unicode テキストレンダリングのサポートがそれです。Factor では、これらのうち、Unicode フォントレンダリングを除くすべての機能をサポートしています。なお、Unicode フォントレンダリングについては、1.0 のリリース前にサポートされる予定です。

Unicode で文字を大文字または小文字に変換するにはどうすればよいですか？

大文字または小文字への変換は、明解に定義された操作ではありません。たとえば、ß という文字は大文字では SS になります。文字によっては、コンテキストによって大文字と小文字のマッピングが変わります。したがって、大文字または小文字に変換する必要がある場合には、個々の文字ではなく、文字列を使ってください。Factor の Unicode ライブラリは、文字のマッピングを実装していません。どうしても不正確になるからです。変換対象が ASCII だけの場合は、そのために定義された文字変換ルーチンがあります。大文字小文字を区別しない比較については、部分的な照合キーを使うのが適切かもしれません。

ボキャブラリがサブボキャブラリを持つことはできますか？

できますが、メインとサブのボキャブラリの間には何の関係もありません。単に名前付け/ディレクトリ構造の面で関係があるだけで、便宜的な関連しかありません。

名前の同じ 2 つのワードをそれぞれ異なるボキャブラリに含めることはできますか？

通常、ワード名が重なるボキャブラリを複数設計する必要はないと思いますが、時には同じワード名を使ったライブラリを 2 つ使いたいケースもあるかもしれません。その場合、解決策は 2 つあります。最も簡単なのは、名前の重なるワードのうち一方だけを使う必要がある場合に、使わない方を USING: 宣言で 2 番目に記述することです。同じ名前のワードを両方とも使う必要がある場合、すなわちもう少し込み入った状況になる場合には、修飾付きライブラリインポートを使用できます。こうすると、修飾付き名前付けを有効にすることができ、foo というボキャブラリを次のようにしてロードきます。

QUALIFIED: foo

ボキャブラリ foo のワード bar にアクセスするには、foo:bar という名前を使います。2 つのボキャブラリで同じ名前が使われている場合は、通常、一方のボキャブラリを USING: 宣言で記述し、もう一方を QUALIFIED: でロードします。