Why Lisp?

  • Simplicity of S-expression: The main reason of adopting Lisp is not because its existing ecosystem, but the simplicity and consistency of the S-expression.
    • Easy to implement its parser. (quite significant for guys like me who have no backgrounds in computer science lol)
    • Infix operator looks much more intuitive, but users need to remember the priority and associativity rules (left-associative or right).
      • It gets much more complex if the language specification allows users to define custom infix operators, Haskell for instance.
    • In S-expression, all operators or keywords are prefixed and the associativity structure is explicit from parentheses.
  • Data as Code: Not talking about Lisp's macro. It syntactically looks like some sort of tree structural data format rather than programming code. It's much more similar to JSON/YAML but with minimal length of characters.
    • The basic idea of Glisp is to introduce a programmatical notion into a static and declarative format of design tools' project file.
    • Easy to handle an expression itself as a value. If you want to write a script to set some expression to certain location of AST, the quote/unquote operators would be useful like below:
      • (set-expr ./layer1/circle/radius \(* a 2))`
      • As the quote operator is intended to represent a list data with avoiding to be evaluated as a function application expression, or is used in the body of function, Glisp uses it to handle a chunk of expression as a value without evaluating it eagerly.
  • ...and it's simply loved in Hacker culture🔥🔥

Why not use XML?

  • XML distincts a main data type which can compose the hirarechy of tags from and other subordinate data types as attributes.
    • e.g. the main data type of HTML is DOM.
  • If you're trying to set an expression to an attribute, you need to embed an another syntax as scripting language after all.
    • e.g. SVG's transform property: <path transform="translate(20, 20) rotate(30deg)" />
    • In S-expression, you can use equivalent syntax on anywhere. (path (vec2/* (translate [20 20]) (rotate 30deg)))
  • If you're trying to implement a dependency graph for an attribute value within the syntax of XML, you need to isolate them in different context and set a reference to it instead of directly setting an expression in scripting language.
    • Some of complex graph of SVG filter effects need to be declared within <def> tag and you have to refer it by url(#idToFilter).
  • Altough .plist is data type agnostic and can be used for any kind of data structure just like JSON or YAML, the syntax that always requires close tags is way more redundant compared to them.

Why not adopt an existing paradigm just like JSX/Virtual DOM?

  • As I mentioned above, embedding another language to represent computed property or structure makes the whole specification too complex and doesn't fit with the declarative flavor.
    • <input disabled={a | b | c} />, obj.map((, i) => <i>{i}</i>)

Isn't Lisp too unfriendly for users to write directly?

  • As its abstract syntax tree is quite simple and it's easy to convert them into a GUI, most users other than advanced ones don't need to read or write the code of Lisp directly.
  • Instead, casual users can manipulate the expression from viewport or inspector, without aware of acutally modifying code.
  • Some people might still think Lisp is not legible as a high-level language, as someone ironically call it “Lots of Irritating Silly Parentheses“, This kind of hardness can be applied for Python, as it requires lots of redundant whitespaces and would be hard as well if you're using an ordinal text editor. What makes languages hard to read/write depends on the existence of appropriate features of code editor such as syntax highlighting and input assistance.
  • Introducing Lisp is just to make software malleable as backend.
  • Lisp evaluator is not a kernel of programming environment. Glisp works as if a wrapper of host language (at present, JavaScript) and introduces a flavor of declarative and functional syntax into imperative way of programming laying on the most of common languages. However, if you willingly want to write in familiar language, you can choose the host language to script as well.

Nagasenaさんへの下書き

Homoiconicityについてですが、Lisp的な構文レベルで改変できてしまうマクロはGUIと相性がわるいと思っています
Glispの場合は、マクロ的な構文は多段階評価（抽象的な表現の構造を少しずつ均していく）にのみ使うことにしています。たとえば、自然数の累乗展開は

pow = (=> (x: number n: nat): number `(* ...~(repeat n `x)))

とすると、

(pow (+ 2 3) 3)
-> (* (+ 2 3) (+ 2 3) (+ 2 3))
-> (* 5 5 5)
-> 125

みたいに少しずつ展開していける、みたいな（構文はまだ悩んでます）

むしろGUIとのバインドで重要なのは、言語の意味論的な解釈を逐次実行される命令列じゃなくて、（書きかけ）