Glispに求められる性質の一つは「AST上のどの項からも評価を始めることが出来る」です。
通常のインタプリタ言語では、そのプログラム全体を表すASTのルートから評価を始め、その項を構成する内側の項を再帰的に先行評価することで、ルートの項が表す値を評価する準備が整います。そして、その評価結果はプログラム全体が返す値となります。
一方Glispは、コードそのものがプロジェクトファイルとして使われることを想定しています。プロジェクトは複数のアートボードを含むかもしれません。あるいは入れ子になったタイムラインを含むかもしれません。通常、アーティストの注意の対象はプロジェクトの一部です。多くの時間を、一つのコンポジションだけを開いたり、レイヤーをソロ表示しながら作業します。アートボードをエクスポートする時、あるタイムラインを動画書き出しする時、評価したいのはプログラムの部分項です。「プログラム（= プロジェクトファイル）全体が返す値」というのは重要ではありません。
それゆえにGlispの評価戦略は、部分評価、遅延評価がベースとなります。ある部分項の評価結果を知るために、プログラム全体を実行するのでは効率が悪いので、その項が依存する最小限の項を評価します。内側の項を先行評価するとともに、そこに含まれるシンボルが参照する項を、ASTの外側へと手繰るように名前解決します。
通常の言語と違い、GlispではアーティストがASTの構造を意識せざるを得ない。なぜなら、ASTの階層関係が、そのままプロジェクトのツリービューやレイヤー階層に反映されるから。ところで、中置記法は多くの言語でサポートされている。二項関係が視覚的にわかり易く、タイプ数を抑えられるためだ。しかしASTの階層構造は、演算子の優先順位や結合性から暗黙的に決められるために理解しづらい。1 + 2 + 3 * 4 というコードは、JavaScriptの内部表現では ((1 + 2) + (3 * 4))のようになる。一方Juliaの場合、中置演算子は2引数とは限らず、任意個の引数を受け取ることができるためにadd(1, 2, mult(3, 4))のようにパースされる。四則演算だけならまだしも、Haskellのように任意の関数を中置演算子として使える言語だと、中置記法からASTの構造をイメージするのはさらに難しくなる。
LispのS式は、ASTの階層が常に括弧で明示されているのでそうした問題が無い。また、可能な限り可変長引数関数として宣言することで、構文木のネストを浅くすることが出来る。ネストが浅いメリットは、1 + 2 + 3 + 4という視覚的には階層がフラットに思える式を、ツリービュー上で
add
├ 1
└ add
├ 2
└ add
├ 3
└ 4
のように表示しなくて済むということです。