Gomamochi

全体の姿

一つのソースと、それを動かす二つの道です。

どちらの道も一つのエンジンに行き着きます。 pixie の C API は一つの共有ライブラリで、どちらの実行もそれを purego で開きます。 cgo は使いません。 解釈実行を担うのは、gomamochi コマンドの中の yaegi です。 コンパイルした実行は、同じファイルから go build が作ったバイナリです。 そのバイナリの横には、同じライブラリを置きます。 エンジンは Go の値を持ちません。 だからインタプリタと、コンパイルしたバイナリとが、まったく同じコードを動かせます。

書いて、動かして、配る

いちばん小さいアプリの全文です。

package main

import (
    "fmt"

    . "github.com/i2y/yokan/gomamochi"
)

type Counter struct {
    count int
}

func (c *Counter) View() Element {
    return Column(
        Text(fmt.Sprintf("count: %d", c.count)).Size(34),
        Button("+1").OnClick(func() { c.count += 1 }),
    ).Spacing(12).Padding(16)
}

func main() {
    Run(&Counter{}, Title("counter"))
}

アプリは構造体です。 状態はそのフィールド、View は要素を一つ返すメソッド、ハンドラはそのフィールドが見えるクロージャです。 継承するものも、登録するものも、監視対象だと印を付けるものもありません。 Go にはキーワード引数がないので、要素のキーワードはその要素のメソッドになっています。 Text("…").Size(34) や Column(…).Spacing(12).Padding(16) のように、キーワードを並べる代わりにメソッドをつないで書きます。

dot import は好みの問題です。 パッケージに名前を付けて import すれば、呼び出しはすべて gm.Text(…)、gm.Run(…) の形になります。 アプリのほうも、自分の型に好きな名前を使えます。 どちらの書き方も、両方の実行が受け取ります。

$ ./bin/gomamochi run app.go

これでウィンドウが開き、ファイルを見はじめます。 編集して保存すると、ウィンドウがそれを取り込みます。 新しいインタプリタがファイルを読み直し、ウィンドウの持っている構造体は、値をすべて保ったまま新しいコードで動きます。 ビルドの手順はありません。 Go のツールチェーンもこのループには要りません。 インタプリタはコマンドの中にあります。

配ります。

$ ./bin/gomamochi build demo/counter.go --release --app
built: demo/.gate/counter/counter (1.9 MB)
bundle: demo/dist/counter.app (22.2 MB)

バイナリは Go のコンパイラが作ったもので、cgo は使いません。 エンジンは一つの共有ライブラリとして、その横に置かれます。 --app は二つを一つのバンドルにまとめます（Linux では AppDir になり、--appimage がそれを一つのファイルに詰めます）。 受け取る人は、Go もツールチェーンも入れずに開けます。

どんな画面になるか

demo/ledger.go。 家計簿をデータベースに置き、値は文に直接書かず ? で渡し、合計を棒グラフにしています。 普通の Go で書かれ、配るときは Go のコンパイラが作るバイナリになります。

「手元では動いたのに」

操作の並びを渡すと、解釈実行とコンパイルしたバイナリの両方でそれを再生し、できあがった画面を突き合わせます。 Gomamochi はこれをゲートと呼びます。

$ ./bin/gomamochi gate app.go --script "click:+1,dump"
GATE OK — 3 dump lines identical in both runs

コンパイルした実行は Go のコンパイラそのものです。 だからゲートが通れば、書いているあいだに見ていたウィンドウが、スクリプトの触れた範囲では配るものと一致していたということです。 違いが出るとすれば、インタプリタのほうです。 違いのある場所は、理由とともに二つの実行に挙げてあります。 どれも、何かを組み立てるより先に断ります。

Go の標準ライブラリは、両方の実行で同じコード

fmt、strings、strconv、math、sort、time、encoding/json、net/http、os は Go 自身のものです。 これらを Gomamochi のライブラリで置き換えてはいません。 インタプリタはコマンドの中にコンパイルされたパッケージを呼び、バイナリは同じパッケージをリンクします。 だから数の書式も、整数のオーバーフローも、文字列の大文字化も同じです。 一致を確かめるための表は要りません。

    sort.Slice(order, func(a, b int) bool { return scores[order[a]] < scores[order[b]] })
    line := fmt.Sprintf("mean %.1f, %d over five", mean, len(big))

データベース、クリップボード、OS のダイアログ、音、通知はフレームワークのものです。 そちらでは、エンジンの中の一つの実装が、C API を通して両方の実行に答えます。

    SqliteExec(db, "INSERT INTO expenses VALUES (?, ?, ?)", name, strconv.Itoa(yen), cat)
    rows := SqliteQueryRowsOr(db, "SELECT name, amount, cat FROM expenses ORDER BY rowid")

移植した二つのゲーム

Pyxel 自身の例（Takashi Kitao、MIT）を二つ、ほぼ 1 行ずつ移してデモに入れてあります。 画素のキャンバスも、毎秒 30 フレームという速さも、押しっぱなしのキーの読み方も同じです。 打鍵とフレームからなるスクリプトが両方の実行を再生するので、ゲートはゲームの全フレームを突き合わせます。

demo/shooter.go と demo/jump.go。 キャンバスの中で色は、配色の何番目かというだけの番号です。 だから、ドット絵の道具のために書かれた描画が、数字を変えずにそのまま移せます。

エージェントが書くとき

エージェントはファイルを書き、返ってきたものを読みます。 だから、返ってくるものの形で作業の進み方が決まります。 三つのコマンドのうち二つは、何もビルドせず、ウィンドウも開かずに、1 秒前後で答えます。 何を書けばよいかが書かれた断りと、文字になった画面です。 最後の証明がゲートです。

ループ全体はエージェントと一緒に書くにあります。

ほかに入っているもの

できないこと

• 解釈実行は yaegi で、その Go は 1.22 のものです。 min と max、数や関数を回す range、そして 1.22 より後に標準ライブラリに入ったものはありません。 最初の三つは、書き直し方とともに断ります。 全体の一覧はツアーの最後の節にあります。
• アプリは 1 ファイルで、import できるのは標準ライブラリとこのパッケージです。 標準ライブラリの外のモジュールは断ります。 インタプリタがまだ読めないからです。
• 配るアプリは、バイナリと、その横に置くエンジンのライブラリの二つです。 この二つをまとめたバンドルでもかまいません。 1 本のファイルにまとめる形はありません。
• dot import のもとでは、パッケージが公開している名前（App、Element、Text、Run など）はすでに埋まっています。 アプリ自身の型には、それを避けた名前を付けます。 パッケージに名前を付けて import してもかまいません。
• Apple シリコンの macOS と Linux。

理由は、ツアーのまだできないことにあります。

次に読むもの

名前は胡麻餅、黒胡麻を練り込んだ餅です。 エンジンを共にする羊羹と若草と落雁と同じく、和菓子から採りました。