トップ   編集 凍結 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS   ログイン

TOP>Squeak

このページの参照数 1746 回

Squeak とは

フリーでオープンな Smalltalk システムのひとつ。または、仮想マシン技術で動作する GUI ベースの OS(厳密にはモドキ)。他の Smalltalk システム同様、ネイティブ言語は Smalltalk 言語だが、Squeak システムではそれとは別に eToys というエンドユーザー向けのビジュアル・スクリプティング環境が新たに追加されている。

Smalltalk システム

'70 年代、XEROX のパロアルト研究所(PARC)で作られた試作機「ALTO」用の OS のひとつ *1 。今やお馴染みの GUI、そして、オブジェクト指向 *2 を本格的に採用した史上初の個人ユーザー向けコンピュータシステムで、後の OS に多くの影響を与えた。結果的に、Smalltalk を OS にした ALTO が世に出ることはなく *3 、Smalltalk は用途を限定した開発環境「Smalltalk-80」 *4 として販売されたため、その後は単なる言語処理系というイメージが定着してしまった。

Smalltalk 言語

Smalltalk システムのネイティブ言語。自身の処理系、言語仕様的部分も含めた基礎部分から、GUI フレームワーク、標準添付のアプリケーション*5にいたる当該システムのほぼ全機能がこの言語により記述されている。さらに、GUI や各種ツールを介して用いることで、エンドユーザー向けスクリプティング言語としても使用できる*6

原則として Smalltalk 言語のコードは式のみで構成される。式はリテラル式*7を除き、

メッセージレシーバ メッセージ

の書式に従う。これを「メッセージ式」と呼ぶ。配列要素へのアクセス、二項式、条件式、条件分岐、ループなど通常の言語では構文の一部などとして定められているものの記述も例外ではない。書式のメッセージレシーバ部分には、リテラル式、オブジェクトを束縛した変数、(オブジェクトを返す*8)別のメッセージ式のいずれかが当てはまる。

メッセージ部分の記述は、Smalltalk 言語でもっともとっつきにくい特徴のひとつであるが、ちょっと変わった関数の呼び出しにすぎない…と考えると比較的理解しやすい。関数は0個以上の引数をとり、関数名には引数と同数の「:」を含む(それ以外はアルファベットのみで構成)。また、引数を1つ以上持つ関数の関数名は「:」で終わらなければならず、引数を2つ以上持つ場合は、「:」を連続させてはいけない*9というルールがある。そして(ここがもっとも変わっているところだが)、メッセージとしての記述の際、引数は、「:」の後に(必要なら前後にスペースを伴わせて)挿入/追記する。

以上に従い、たとえば、次のようなものが典型的なメッセージ式となる。

Point x: 3 y: 4    "Point がレシーバ、x: 3 y: 4 がメッセージ"
                   "#x:y: が関数名、3 と 4 が引数"

なお、一般的な言語の書式では、これは Point.x:y:(3,4) というふうに書くことができる*10。他方で、二項式に相当するメッセージ式は「二項メッセージ式」と呼ばれ、関数名がアルファベットではなく記号のみより成り立つ点で異なるが、ほぼ同じ考え方に従って解釈する。

3 + 4              "3 がレシーバ、+ 4 がメッセージ"
                   "#+ が関数名、4 が引数"

Smalltalk では、関数を「メソッド」、関数名を「セレクタ」*11と呼ぶ。なお、セレクタの実体はシンボル*12であることから、そのリテラル記述の際に使用する「#」を冠して、#x:y:、#+ などと表現するのが一般的である。*13

関数、つまりメソッドは単独での存在を許されず、必ず何かしらのクラスに明示的に内包される。また、メッセージ式(つまり、インスタンスへのメッセージ送信)を介さずに関数を直接“名指し”で起動することはできない*14。Smalltalk 言語には組み込みの関数というものはなく*15、そのすべてが、システムに付随するクラスライブラリを介して提供されている。これに動的型システムである(変数に型がない)ことを言い添えれば、以上が、言語仕様のほぼすべて。LISP に次いで単純な仕様の言語と言える。

ただこれだけでは Smalltalk 言語の何も理解したことにならないので、実際に使用するにあたっては、本来の言語仕様的な部分を定める(ディストリビューションに共通して含まれる)基本的なクラスに対する理解はもちろん、GUI や各種ツール群について最低限の知識もまた、別に必要になる。

Squeak eToys (SqueakToys, eToys)

Squeak システムに標準で装備されたビジュアルスクリプト言語とその環境。Smalltalk 言語で組まれているが、Smalltalk 言語とはまったく別の仕様を持つ*16。言語としての大きな違いは、コードがメッセージ式で構成されないこと、静的型システムである(変数に型がある)こと、インスタンスベース*17である(インスタンスがメソッドを持てる)こと、など。

ユーザーは、「モーフ」という可視化したオブジェクト(簡単には、ドロー系描画ツールの基本図形のようなもの)に対し、スクリプトを記述する*18。スクリプティングは、各モーフに対応する「ビューワ」と呼ばれるある種のコントロールパネルから、「フレーズ」と呼ばれるタイル状の機能を意味する矩形を取り出し、それらをドラッグ&ドロップ操作で組み合わせることで行なう。キー入力は原則として必要でない。

リンク

コメント/通信欄

[とりあえずページを作っただけなので、これから書きます・・・詳しい方、書いてください(笑)--機械]

[では、とおりいっぺんに。w --sumim]

[説明感謝です・・・私じゃここまで書けない --機械]

[恐縮です。このくらいならおやすい御用です。他に、書いておいたほうがよい情報、知りたいことがありましたらお気軽に。最近は Python もかじっておりますので、ちょっとした比較や対比なども可能です。--sumim]

[項目増やしてみました。特にSmalltalk言語(オブジェクト指向プログラミング言語)については私もまだまだ勉強中なので、C++系言語(含むPython etc)との比較について何か書いていただければ幸いです。--機械]

[どこからはじめたらいいか分からなかったので、とりあえず、言語仕様の初歩の初歩だけ書いてみました。さて、ここからどうやって C++ などとの比較に繋げましょうか…。w --sumim]

[C++言語 とSmalltalk言語の大きな違いは、やはりブロックだと思うんですが、そこまでつなげるのって大変ですよねぇ・・--機械]

[考えたのですが、言語の違いよりは、2つのオブジェクト指向の着眼点の違いを整理したほうがよいと思います。端的には、メッセージでどう表現するか、か、データ型でどう表現するか、です。どちらに軸足を置くかはユーザー次第。たまたま、Smalltalk 言語は前者に C++ は後者に重きを置くと幸せになれるように作られている…と。 Python は両者にバランスがとれているから好かれるんでしょうかね(逆に、私のように極度に前者寄りのスタンスだと物足りないw)。--sumim]

[まぁ、C++は実際はどうとでも書けると思うのですが、メッセージで全てを表現するようにC++で書くと、非常に面倒臭いというだけで・・・(そこらへんを改善したのがPython、という感じです)。SmalltalkはGUIのようなオブジェクトでイメージしやすいものをイジるには気持ちがいいんですが、フツーの計算とかは、やや特殊な思考をするように訓練しないと、つらいですからね。私はC++の一番の不幸は、そもそも汎用言語として設計されているとは思えないにも係らず、あまりにも使われすぎているということにあると思います。適材適所でそれぞれが使えるように、どこに使うべきなのかがイメージできるような、各言語のオブジェクトへのアプローチの違いの説明があると嬉しいです(いや、私も実はあんまりわかってないんですが・・・)--機械]

[私は、C++ の最大の不幸は(アラン・ケイも似たようなことに言及しているのですが)、C++ ユーザーが、C++ の設計者であるストラウストラップの主張する「オブジェクト指向」をきちんと理解して活用できなかったことにあると考えています。もちろん、ストラウストラップが彼のまとめた「(ユーザー定義型による抽象化手法)+(継承、仮想関数による動的結合)」をもって、まぎらわしくも(すでにケイらが別の意味で使っていた)「オブジェクト指向」と称してしまったことにも責任はあるとは思います(^_^;)。歴史に“もし”は禁物ですが、もし、ケイが最初に考えたそれを当初のまま「メッセージ指向」と呼び続け、ストラウストラップが自分が考えた別のものをそれに相応しい「クラス指向」と名付けていたなら、(もちろん「オブジェクト指向」という言葉は産まれませんでしたが、同時に)現在のような混乱はなかったはずです。--suimim]

[そもそもオブジェクトという言葉自体が、プログラミング用語の世界で様々に使われていることを考えると、オブジェクト指向という用語自体、命名があまりにも軽卒だったかもしれませんね・・・私自身の経験では、C++を覚え始めた時にCのオブジェクト(メモリ領域を持ったもの)やアセンブラのオブジェクトファイルとごっちゃになって、難儀した覚えがあります・・・って、こんな経験は無いのかな、普通は(苦笑)。現在私は、高校の情報の授業では、データ+手続きの一体化と、オブジェクトにメッセージを送る手法、という感じで生徒に教えてます(充分理解してない講師が教えるってのは、考えてみれば怖いなぁ)あ、3学期から、多分このままだと、授業にSqueakを使う予定です。多分、タイルスクリプティングがメインだけど・・・。--機械]

[Squeak実習、希望者が少なくて中止に(泣) 対抗馬は「Wordの使い方」だから、なんかやりきれないものが・・・Wordなんて使うより、Squeakで遊んだほうが面白いと思うんだけどなぁ・・・--機械]


*1 ALTO = GUI(の元祖)というイメージが強いが、ALTO のいくつかある OS の中で本格的に GUI を採用した OS は Smalltalk だけ。なお、Smalltalk を OS として動作する ALTO は「暫定ダイナブック」と呼ばれた。'79、PARC の見学でジョブズたちが観たのも ALTO というよりはこの暫定ダイナブック。
*2 ただし、ここでのオブジェクト指向はカプセル化・継承・多態性の三要素で知られる C++ 由来のオブジェクト指向ではなく「すべてをオブジェクトとそれに対するメッセージ送信で表現すべし」というドグマにもとづく考え方。本来、両者は区別されるべきだが、渾然一体として語られることが多く、混乱の元となっている。メッセージ指向とも。
*3 同じ XEROX だが PARC ではない部署で作られた別の GUI ベース OS「Star」を搭載し、パソコンではなくワークステーションとして販売された。暫定ダイナブックの販売が却下されたのも、Star のせいと言われている。
*4 現在も、VisualWorks として販売されている。ちなみに Squeak は、発掘された Smalltalk-80 のサブセット( Apple 社向けにライセンスされた古い MC68000 Mac 用 Apple Smalltalk)をベースに作られたので、VisualWorks とは遠い親戚ならぬ、パラレルワールドの同一人物。
*5 見せ方でアプリケーションソフトのように思わせているだけで、実際には、通常の OS におけるアプリケーションソフトに相当するものはない。
*6 というか、Smalltalk システムは、エンドユーザーと開発者(システム記述者やアプリケーション構築者)の区別を原則としてしない。ただ、逆にこのポリシーは、古くより Smalltalk を開発環境としてしか認識しない無理解をはびこらせ、その進化を妨げてしまってもいる。
*7 簡単には、オブジェクトを直接生成する式のこと。念のため。
*8 Smalltalk の式、つまり、メッセージ式は要不要に関わらず必ず返値を持つ。void はない(あるいはそうした指定はできない)、ということ。
*9 ただし、同種の記法を採用した Objective-C ではこれを許している。
*10 「:」も関数名に含まれることに注意。たとえば、foo と foo: ならば、両者は、引数の数(0 vs 1)以前に、まず、名前の違い(#foo は #foo: と等しくない)で区別される。
*11 もちろん、素直に「メソッド名」でもよい。
*12 等価なとき同一性が保証され、かつ、内容を変更できない特殊な文字列オブジェクト。
*13 さらに、それを内包するクラスを明示的にして、Integer >> #+、Float >> #+、Fraction >> #+ などと記するのがより正式。
*14 実はできたりもするが、ふつうはそういうことはしない。こうした「できるけどやらない」といった暗黙の了解や紳士協定、古くからの慣習が Smalltalk には実に多い。「Smalltalk は書物からでは学べない」というようなことが言われるのも、そのため。
*15 区別としてあるのは、ディストリビューションに最初から含まれていたか、あとからユーザーが追加しなければならないか程度で、それすら定義を終えた瞬間(あるいはモジュールなどでシステムに追加された直後)から区別は意味をなさなくなる。
*16 たとえば、Ruby は C 言語で組まれているが、Ruby と C 言語はまったく異質の言語である、のと同じ。
*17 プロトタイプベースとも言う。クラスがない(言語仕様に含まれない)ことが強調されがちだが、これは本質ではない。
*18 厳密には、スクリプティングは「プレーヤ」と呼ばれる不可視のオブジェクトに対し行なわれる。モーフは、プレーヤのまとう「コスチューム」に過ぎない。

Last-modified: 2022-07-21 (木) 20:49:06