MEP 28: 前景色の取得

Created: 2025-11-13 15:07:00
Updated: 2025-11-15 14:42:00
Status: Supported(v1.0.08)

モチベーション

FireAlpacaの集中線や流線などのフィルタは、現在のブラシの色で線を描く。これと同じ機能を実現できるように、現在の色を取得できるようにしたい。

提案： builtin関数として提供する

rand()などと同様にfore_color()などを提供する。

仕様としてはこちらの方が普通か。たとえば背景色が必要になった時に back_color() とすぐに追加できそう。

一方処理系の実装としては少し不自然さがある。カーネルという視点で見ればこれもparamの一種になるだろうし、言語処理系とアプリケーションの繋ぎを考えると、新しく関数を追加するごとにランタイムに何かAPIが追加されるのも良くない気がする。

検討

大体paramにするか関数にするかの二択だと思っている。paramにする場合どうなるか、と、両者の比較をしていきたい。

paramにしないのか？（COLOR_PICKERの類似の概念では無いのか？）

COLOR_PIKCERと同じようなwidgetの種類として、paramにFORE_COLORというのを追加する、という案も考えられる。

@param_f32v4 fgcol(FORE_COLOR)

これはカラーピッカーとほとんど同じなため、言語処理系とアプリを繋ぐ所のインターフェースは追加の要素がいらない、というメリットがある。一方、ウィジェットが出ないものをparamにするのは違和感もある。

両者の比較の議論

言語の仕様としてはbultin関数の方が良い気がする。ユーザーとしても慣れ親しんだ普通の形なので、学習しやすいだろう。

一方で処理系としてはparamの方がいい気もする。シェーダーのレイヤーで考えるとカーネルに対するパラメータであるのは間違いないし、関数が増える都度ランタイムを呼ぶ側でやらないといけない事が増えていくのは望ましくない。少なくともカーネルにはParamInfoとして渡す事になるし、それはIRBinaryが持つ事にもなるだろう。

ただしこの辺は実装の詳細、という話であって、言語仕様の話には感じられない気もする。

言語の仕様としてはユーザーの学びやすさを優先したいか。内部の実装をどうするべきかはおいといて、仕様としてはbuiltinを採用しよう。