{"data":{"post":{"title":"A Glimpse into Swift Generic Meta-Programming","subtitle":"Make VFL Reborn in Swift with Compile-Time Safety","isPublished":true,"createdTime":"2019-03-27T00:00:00.000Z","lastModifiedTime":null,"license":null,"tags":["Swift","MetaProgramming","Generic","VFL","AutoLayout","macOS","iOS","tvOS"],"category":"Programming","file":{"childMdx":{"excerpt":"Preface What is the most critical thing swings your decision when you choose a\nprogramming language…","code":{"body":"function _objectWithoutProperties(source, excluded) { if (source == null) return {}; var target = _objectWithoutPropertiesLoose(source, excluded); var key, i; if (Object.getOwnPropertySymbols) { var sourceSymbolKeys = Object.getOwnPropertySymbols(source); for (i = 0; i < sourceSymbolKeys.length; i++) { key = sourceSymbolKeys[i]; if (excluded.indexOf(key) >= 0) continue; if (!Object.prototype.propertyIsEnumerable.call(source, key)) continue; target[key] = source[key]; } } return target; }\n\nfunction _objectWithoutPropertiesLoose(source, excluded) { if (source == null) return {}; var target = {}; var sourceKeys = Object.keys(source); var key, i; for (i = 0; i < sourceKeys.length; i++) { key = sourceKeys[i]; if (excluded.indexOf(key) >= 0) continue; target[key] = source[key]; } return target; }\n\nconst layoutProps = {};\nreturn class MDXContent extends React.Component {\n constructor(props) {\n super(props);\n this.layout = null;\n }\n\n render() {\n const _this$props = this.props,\n {\n components\n } = _this$props,\n props = _objectWithoutProperties(_this$props, [\"components\"]);\n\n return React.createElement(MDXTag, {\n name: \"wrapper\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"h2\",\n components: components\n }, `Preface`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `What is the most critical thing swings your decision when you choose a\nprogramming language?`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Some people may say, the less lines of code they write, the better the\nlanguage itself is. (Nope, the best programming language is PHP.)`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `OK. It might be true. But writing less code is not an essential indicator\nthat truely leads a programmer to write less code. There is a better way\nwhere to inspect what primitives a programming language has.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `There are some old-school programming languages which may not have\nmulti-dimensional array. This leads an array cannot hold another one in\nitself and disallows developers to invent some recursive data structures\nand limits the expressiveness of the language. The expressiveness of a\nprogramming language, formally, is the `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `computational capability of a\nprogramming language`), `.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `But the array example I mentioned above is just about runtime\ncomputational capability. What about the compile-time's?`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `For languages like C++, they have an explicit compile process and a \"code\ntemplate\" infrastructures to do some compile-time computations by collecting\nthe pieces of the source code and then organizing them into a piece of new\ncode. You may have heard a buzz word: \"meta-programming\". Yes, this just is\nmeta-programming (but at compile-time) and there is a bunch of programming\nlanguages includes C and Swift can do compile-time meta-programming.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Meta-programming in C++ relies on templates. In Swift, it relies on generics.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Though you can do compile-time meta-programming in these three programming\nlanguages, the capability of them are different. Since there are a lot of\nposts on the Internet that talked about the reason why C++ template is\n`, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `turing complete`), ` (a measurement of computational capability, you can just\nbriefly treat it as \"be able to compute anything that a normal computer is\nable to compute\"), I don't want to waste my time on explaining it again\nhere. What I'm going to talk about is Swift generics which also can do\nmeta-programming at compile-time but owns a compile-time computability of\n`, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `push-down automata`), `. You can briefly treat is as \"is able to compute\nthings with finite or recursive patterns.\"`), React.createElement(MDXTag, {\n name: \"hr\",\n components: components\n }), React.createElement(MDXTag, {\n name: \"h2\",\n components: components\n }, `Case Study : VFL Compile-Time Safety`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `There are a lot of Auto Layout helper libraries: Cartography, Mansory,\nSnapKit... But, are they really good? What if there were a Swift versioned\nVFL which ensures the correctness at compile-time and can collaborate with\nXcode's code completion?`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Truth be told, I'm a fan of VFL. You can lay many views out by using one\nline of code with intuitive symbols. With Cartography or SnapKit, things\nalways go tedious.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Since the original VFL has some issues with modern iOS design, which\ncannot cooperate with layout guides, you may also want layout guide\nsupport in this set of API that we are going to implement.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Finally, in my production code, I built the following API which ensures\ncompile-time safety and supports layout guide.`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `// Make constraints and install to view hierarchy\n\nconstrain {\n withVFL(H: view1 - view2)\n \n withVFL(H: view.safeAreaLayoutGuide - view2)\n \n withVFL(H: |-view2)\n}\n\n// Just make constraints\n\nlet constraints1 = withVFL(V: view1 - view2)\n\nlet constraints2 = withVFL(V: view3 - view4, options: .alignAllCenterY)\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Just imagine that how many lines of code you need for building equivalent\nthings with Cartography or SnapKit? Cannot wait to know how I build it?\nLet's go for it.`), React.createElement(MDXTag, {\n name: \"h3\",\n components: components\n }, `Transforming the Grammar`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `If we dump the original VFL grammar into Swift source code by trimming the\nstring literal quotes, then it will soon be found that some characters\nused by the original VFL such as `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `[`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `]`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `@`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `(`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `)`), ` is not allowed\nin operator overloading in Swift source code. Thus I transformed the\noriginal VFL grammar into the following grammar:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `// Original VFL: @\"|-[view1]-[view2]\"\nwithVFL(H: |-view1 - view2)\n\n// Original VFL: @\"[view1(200@20)]\"\nwithVFL(H: view1.where(200 ~ 20))\n\n// Original VFL: @\"V:[view1][view2]\"\nwithVFL(V: view1 | view2)\n\n// Original VFL: @\"V:|[view1]-[view2]|\"\nwithVFL(V: |view1 - view2|)\n\n// Original VFL: @\"V:|[view1]-(>=4@200)-[view2]|\"\nwithVFL(V: |view1 - (>=4 ~ 200) - view2|)\n`)), React.createElement(MDXTag, {\n name: \"h3\",\n components: components\n }, `Figuring Out the Implementations`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `How to achieve this design?`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `An intuitive answer is to use operator overload.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Yes. I've done this with operator overload in my production code. But how\ndoes the operator overloading work here? I mean, why the operator\noverloading is able to convey our design?`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Before answering the question above, let's check out some examples.`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `withVFL(H: |-view1 - view2 - 4)\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The code above is an illegal input shall not be accepted. The relative\noriginal VFL is below:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-objectivec\"\n }\n }, `@\"|-[view1]-[view2]-4\"\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `We can find that there is missing view object or a `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-|`), ` after `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `4`), `.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The system is expected to be able to handle correct inputs by making the\ncompiler to accept it and also to handle incorrect inputs by making the\ncompiler to reject it (because this is what `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `compile-time safety`), ` means).\nThe secrete behind this is not some black magic which applied by an mystic\nengineer whom has got a very high level title, but simply to make the\ncompiler accept user inputs by matching user inputs with a defined function\nand to reject user inputs by mismatching user input with all defined\nfunctions.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `For example, like the `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1 - view2`), ` in a part of the example above, we\ncan design the following function to handle it:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `func - (lhs: UIView, rhs: UIView) -> BinarySyntax {\n // Do something really combine these two views together.\n}\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `If we take the `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `UIView`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `BinarySyntax`), ` in the code block above as two\nstates, then we can read the code above as \"a `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `UIView`), ` transitions into\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `BinarySyntax`), ` when there is another `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `UIView`), ` input with overloaded operator\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-`), `. Such a simple state transition is trivial. But it is the basic building\nblock of the system.`), React.createElement(MDXTag, {\n name: \"h3\",\n components: components\n }, `Naïve State Transitioning`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The state transition with types and overloaded operator example I shown\nabove may give you an intuition: we can build the system by enumerating all\npossible state transitions!`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `But... How many types we are gonna create with this solution?`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `What you may not know is that: VFL is expressible by a DFA, whose\ncomputability is a subset of push-down automata -- This is critical. Since\nwe cannot build a system upon an weaker underlying system.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Yes. Since recursive texts like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `[`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `]`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `(`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `)`), ` are not really\nrecursive in VFL (only one level of them can appear in a correct VFL\ninput and cannot be nested), a DFA is able to express the complete\npossible input set of VFL.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Thus I created a DFA to simulate the state transitions of `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `our design`), `.\nWatch out! I didn't take layout guide into consideration in this figure.\nIntroducing layout guide may make the DFA much more complicated.`), React.createElement(MDXTag, {\n name: \"blockquote\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `To know more about recursiveness and DFA with a plain and brief\nintroduction, you can check out this book:\n`, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"p\",\n props: {\n \"href\": \"http://shop.oreilly.com/product/0636920025481.do\"\n }\n }, `Understanding Computation: From Simple Machines to Impossible Programs`))), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"img\",\n components: components,\n parentName: \"p\",\n props: {\n \"src\": \"/ctvfl-automaton-a09b2bbe2930700eec53996fee32b123.svg\",\n \"alt\": \"CTVFL Automaton\",\n \"title\": \"CTVFL Automaton\"\n }\n })), React.createElement(MDXTag, {\n name: \"blockquote\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `In the diagram above, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|pre`), ` means prefix `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|`), ` operator and respectively\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|post`), ` means postfix `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|`), ` operator, double circle means an accepting\nstate and single circle means a receiving state.`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Counting the types we are gonna create is a complex task. Since there are\nbinary operators `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-`), `, and there are unary operators `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|-`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-|`), `,\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|prefix`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|postfix`), `, the counting method varies over these two kinds\nof operators:`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `A binary operator consumes two input states but an unary operator consumes\none. Each operator creates a new type.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Since even the counting method itself is too complex, I would rather to\nexplore another approach...`), React.createElement(MDXTag, {\n name: \"h3\",\n components: components\n }, `State Transitioning with Multiple States`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `I drew the DFA diagram above by deadly putting possible characters to test\nwhether a state receives them or not, this maps all the things into one\ndimension. May be we can create a cleaner expression by abstract the\nproblem in multiple dimensions.`), React.createElement(MDXTag, {\n name: \"blockquote\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `Before the beginning of further exploration, we have to acquire some\nbasic knowledge about Swift operator's associativity.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `The associativity of an operator (strictly speaking, of a binary\noperator, which means an operator connects a left-hand-side operand and\nright-hand-side operand, just like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-`), `) is for which side of an\noperator, a compiler may prefer to use it as a parent node for\nconstructing descendant sub syntax tree. The default associativity of\nSwift operator is left, which means the compiler prefer to use the\nleft-hand-side of an operator to construct a syntax tree. Thus we can know\nfor a syntax tree of a left associative operator, it is visually\nleft-leaning.`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Firstly, let's write down some simplest syntaxes:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `// Should accept\nwithVFL(H: view1 - view2)\n\n// Should accept\nwithVFL(H: view1 | view2)\n\n// Should accept\nwithVFL(H: |view1|)\n\n// Should accept\nwithVFL(H: |-view1-|)\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The syntax tree of them are below:`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"figure\",\n components: components,\n parentName: \"p\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"figure\",\n props: {\n \"href\": \"/static/b39c2fc7047c623702bd293b8caf6219/917ab/simple-syntaxes.png\"\n }\n }, React.createElement(MDXTag, {\n name: \"img\",\n components: components,\n parentName: \"a\",\n props: {\n \"title\": \"Syntax Trees for Simple Syntaxes\",\n \"alt\": \"Simple Syntaxes\",\n \"src\": \"/static/b39c2fc7047c623702bd293b8caf6219/917ab/simple-syntaxes.png\",\n \"srcSet\": [\"/static/b39c2fc7047c623702bd293b8caf6219/917ab/simple-syntaxes.png 1x\", \"/static/3ac510faf8b4a4da1af9f736ed76d3cf/f4d2f/simple-syntaxes%402x.png 2x\", \"/static/54693ec047d950f70fa7ebe70a960823/0d143/simple-syntaxes%403x.png 3x\"],\n \"loading\": \"lazy\"\n }\n })), `\n `, React.createElement(MDXTag, {\n name: \"figcaption\",\n components: components,\n parentName: \"figure\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"span\",\n components: components,\n parentName: \"figcaption\"\n }, `\n Syntax Trees for Simple Syntaxes\n `), `\n `))), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Then we can split the case into two:`), React.createElement(MDXTag, {\n name: \"ul\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"li\",\n components: components,\n parentName: \"ul\"\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"li\"\n }, `Binary syntaxes like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1 - view2`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1 | view2`), `.`)), React.createElement(MDXTag, {\n name: \"li\",\n components: components,\n parentName: \"ul\"\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"li\"\n }, `Unary syntaxes like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|view1`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1-|`), `.`))), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `This makes us to intuitively create two types:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `struct Binary { ... }\n\nfunc - (lhs: Lhs, rhs: Rhs) -> Binary { ... }\n\nfunc | (lhs: Lhs, rhs: Rhs) -> Binary { ... }\n\nstruct Unary { ... }\n\nprefix func | (operand: Operand) -> Unary { ... }\n\npostfix func | (operand: Operand) -> Unary { ... }\n\nprefix func |- (operand: Operand) -> Unary { ... }\n\npostfix func -| (operand: Operand) -> Unary { ... }\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `But is this enough?`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `Syntax Attribute`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Soon it will be found that we can plug anything on the `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Lhs`), ` or `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Rhs`), ` of a\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Binary`), `, or the `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Operand`), ` of a `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Unary`), `. To make the compiler really can\nreject inccorect user inputs. We have to do some limitations.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Typically, inputs like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|-`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-|`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|prefix`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|postfix`), ` shall only be\nappeared the at head and tail side of the syntax. We also want to support\nlayout guide (such as `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `safeAreaLayoutGuide`), `), which also should only be\nappeared at the head and tail side of the syntax. Thus we have to constrain\nthese stuffs to ensured that they are only at the head and tail side of the\nsyntax.`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `|-view-|\n|view|\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Moreover, inputs like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `4`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `>=40`), ` shall only be appeared when paired with\npreceding and succeeding view/superview or layout guide.`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `view - 4 - safeAreaLayoutGuide\n\nview1 - (>=40) - view2\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The above study of the syntax hinted us to split all things in the syntax\ninto three groups: `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `layout'ed object`), ` (views), `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `confinement`), ` (layout\nguides and things wrapped by `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|-`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-|`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|prefix`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|postfix`), `), and\n`, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `constant`), `.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Now we are going to change our design into:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `protocol Operand {\n associatedtype HeadAttribute: SyntaxAttribute\n \n associatedtype TailAttribute: SyntaxAttribute\n}\n\nprotocol SyntaxAttribute {}\n\nstruct SyntaxAttributeLayoutedObject: SyntaxAttribute {}\n\nstruct SyntaxAttributeConfinment: SyntaxAttribute {}\n\nstruct SyntaxAttributeConstant: SyntaxAttribute {}\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Then for specific combinations of syntaxes like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1 - 4 - view2`), `, we\ncan make the following syntax types.`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `/// connects \\`view - 4\\`\nstruct LayoutableToConstantSpacedSyntax: \n Operand where \n /// Checks the tail part of the lhs syntax is a layouted object\n Lhs.TailAttribute == SyntaxAttributeLayoutedObject,\n /// Checks the head part of the rhs syntax is a constant\n Rhs.HeadAttribute == SyntaxAttributeConstant\n{\n typealias HeadAttribute = Lhs.HeadAttribute\n typealias TailAttribute = Lhs.TailAttribute\n}\n\nfunc - (lhs: Lhs, rhs: Rhs) -> LayoutableToConstantSpacedSyntax { ... }\n\n/// connects \\`(view - 4) - view2\\`\nstruct ConstantToLayoutableSpacedSyntax:\n Operand where\n /// Checks the head part of the lhs syntax is a constant\n Lhs.TailAttribute == SyntaxAttributeConstant,\n /// Checks the tail part of the rhs syntax is a layouted object\n Rhs.HeadAttribute == SyntaxAttributeLayoutedObject\n{\n typealias HeadAttribute = Lhs.HeadAttribute\n typealias TailAttribute = Lhs.TailAttribute \n}\n\nfunc - (lhs: Lhs, rhs: Rhs) -> ConstantToLayoutableSpacedSyntax { ... }\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `By conforming to the protocol `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Operand`), `, a type indeed have got two\ncompile-time storage whose names are `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `HeadAttribute`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `TailAttribute`), `,\nand values are of type of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `SyntaxAttribute`), `. By calling the\nfunction `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-`), ` (anyone in the above code block), the compiler checks if the\nleft-hand-side and right-hand-side matches any function with the name `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-`), `\nby reading generic constraints of the result\ntype (`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `ConstantToLayoutableSpacedSyntax`), ` or\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `LayoutableToConstantSpacedSyntax`), `). If it succeeded, we can say that: the\nstate has successfully transitioned to another.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `We can see that, since we've set `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `HeadAttribute = Lhs.HeadAttribute`), ` and\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `TailAttribute = Lhs.TailAttribute`), ` in the body of the types above, the\nhead and tail attribute of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Lhs`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Rhs`), ` is transferred from `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Lhs`), ` and\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Rhs`), ` to the newly synthesized type now. The value is stored in the type\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `HeadAttribute`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `TailAttribute`), `.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Then we've got our functions which make the compiler to receive input like\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1 - 4 - view2`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1 - 10 - view2 - 19`), `... Wait! `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1 - 10 - view2 - 19`), `???\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1 - 10 - view2 - 19`), ` shall be an illegal input which may be rejected\nby the compiler!`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `Syntax Boundaries`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Actually, what we did above just have ensured that a view is consecutive\nto a number and a number is consecutive is a view, it has nothing to do\nwith whether the syntax shall be beginning with a view (or layout guide)\nand end with a view (or layout guide).`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `To make a syntax always begins or ends with a view, layout guide or anything\nlike `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|-`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-|`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|prefix`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|postfix`), `, we have to build a logic to\nhelp our types to `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `\"filter\"`), ` those invalid input out, just like what we\ndid like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Lhs.TailAttribute == SyntaxAttributeLayoutedObject`), ` and\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Rhs.HeadAttribute == SyntaxAttributeConstant`), ` above. We can find that\nthere are actually two groups of syntax mentioned in this kind of syntax:\n`, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `confinement`), ` and `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `layout'ed object`), `. To make a syntax always begins\nor ends with syntax in this two groups, we have to use compile-time `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `or`), `\nlogic to implemented it. Write it down in runtime code, it is:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `if (lhs.tailAttribute == .isLayoutedObject || lhs.tailAttribute == .isConfinment) &&\n (rhs.headAttribute == .isLayoutedObject || rhs.headAttribute == .isConfinment)\n{ ... }\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `But this logic cannot be simply implemented with Swift compile-time\ncomputation because that the only logic of Swift compile-time computation is\nthe `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `and`), ` logic. Since we can only use `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `and`), ` logic in type constraints in\nSwift (by using the `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `,`), ` symbol between\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Lhs.TailAttribute == SyntaxAttributeLayoutedObject`), ` and\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Rhs.HeadAttribute == SyntaxAttributeConstant`), ` in the example above), we can\nonly merge\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `(lhs.tailAttribute == .isLayoutedObject || lhs.tailAttribute == .isConfinment)`), `\nand\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `(rhs.headAttribute == .isLayoutedObject || rhs.headAttribute == .isConfinment)`), `\nin the above code block into one compile-time storage value then use the\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `and`), ` logic to concatenate them.`), React.createElement(MDXTag, {\n name: \"blockquote\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `In fact, the `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `==`), ` in `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Lhs.TailAttribute == SyntaxAttributeLayoutedObject`), `\nor `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `Rhs.HeadAttribute == SyntaxAttributeConstant`), ` is equivalent to the\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `==`), ` operator in many programming languages. Moreover, there is a `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `>=`), `\nequivalent operator in Swift's compile-time computation which is `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `:`), `.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `Considering the following code:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components,\n parentName: \"blockquote\"\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `protocol One {}\nprotocol Two: One {}\nprotocol Three: Two {}\n\nstruct GreaterThanOrEqualToTwo where T: Two {}\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `Now we can compose a generic specialization like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `GreaterThanOrEqualToTwo`), `\nwhich to make Swift compiler accept this specialization. Also we can\ncompose another generic specialization like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `GreaterThanOrEqualToTwo`), `\nto make the compiler reject the specialization.`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Then we can change our design into:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `protocol Operand {\n associatedtype HeadAttribute: SyntaxAttribute\n \n associatedtype TailAttribute: SyntaxAttribute\n \n associatedtype HeadBoundary: SyntaxBoundary\n \n associatedtype TailBoundary: SyntaxBoundary\n}\n\nprotocol SyntaxBoundary {}\n\nstruct SyntaxBoundaryIsLayoutedObjectOrConfinment: SyntaxBoundary {}\n\nstruct SyntaxBoundaryIsConstant: SyntaxBoundary {}\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `This time, we added two new compile-time storagies: `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `HeadBoundary`), ` and\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `TailBoundary`), `, and their values are of type of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `SyntaxBoundary`), `. For view\nor layout guide objects, they offer head and tail two boundaries of\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `SyntaxBoundaryIsLayoutedObjectOrConfinment`), `. When calling the `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-`), `\nfunction, the a view or layout guide's boundary info transferred to the\nnewly synthesized type.`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `/// connects \\`view - 4\\`\nstruct LayoutableToConstantSpacedSyntax: \n Operand where \n /// Checks the tail part of the lhs syntax is a layouted object\n Lhs.TailAttribute == SyntaxAttributeLayoutedObject,\n /// Checks the head part of the rhs syntax is a constant\n Rhs.HeadAttribute == SyntaxAttributeConstant\n{\n typealias HeadBoundary = Lhs.HeadBoundary\n typealias TailBoundary = Rhs.TailBoundary\n typealias HeadAttribute = Lhs.HeadAttribute\n typealias TailAttribute = Lhs.TailAttribute\n}\n\nfunc - (lhs: Lhs, rhs: Rhs) -> LayoutableToConstantSpacedSyntax { ... }\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Now, we just have to modify the signature of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `withVFL`), ` series functions into:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `func withVFL(V: O) -> [NSLayoutConstraint] where\n O.HeadBoundary == SyntaxBoundaryIsLayoutedObjectOrConfinment,\n O.TailBoundary == SyntaxBoundaryIsLayoutedObjectOrConfinment\n{ ... }\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Then, only syntaxes whose boundaries are of layout guide or views can be\naccept.`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `Syntax Associativity`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `But the concept of syntax boundaries still cannot help stop the compiler\nfrom accepting inputs like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1-| | view2`), ` or `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view2-| - view2`), `. This is\nbecause that even the `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `boundaries`), ` of a syntax is ensured, you cannot\nensure the inner part of the syntax is `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `associable`), `.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Thus we introduce the third pair of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `associatedtype`), ` in our design:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `protocol Operand {\n associatedtype HeadAttribute: SyntaxAttribute\n \n associatedtype TailAttribute: SyntaxAttribute\n \n associatedtype HeadBoundary: SyntaxBoundary\n \n associatedtype TailBoundary: SyntaxBoundary\n \n associatedtype HeadAssociativity: SyntaxAssociativity\n \n associatedtype TailAssociativity: SyntaxAssociativity\n}\n\nprotocol SyntaxAssociativity {}\n\nstruct SyntaxAssociativityIsOpen: SyntaxAssociativity {}\n\nstruct SyntaxAssociativityIsClosed: SyntaxAssociativity {}\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `For syntax like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|-`), `, `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-|`), ` or layout guide in a syntax, we can just\ndisable their associativity in new type's synthesize progress.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `It this enough?`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Yes. Actually, I'm cheating here. You may wonder that why I can quickly\nspot issues by enumerating some examples and say yes to the question above\nwithout any hesitation. The reason is that I've already enumerated all the\nsyntax tree constructions on paper. Planning on paper is a good habit for\nmaking things prepared.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Now the core concept of the syntax tree's design is very close to my\nproduction code. You can check it out at `, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"p\",\n props: {\n \"href\": \"https://github.com/WeZZard/CTVFL/tree/master/CTVFL/Syntaxes\"\n }\n }, `here`), `.`), React.createElement(MDXTag, {\n name: \"h3\",\n components: components\n }, `Generating NSLayoutConstraint Instances`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `OK. Come back. We still have something to implement, which is\ncritical to our whole work -- generate layout constraints.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Since the actual thing we get in the argument of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `withVFL(V:)`), ` function\nseries is a syntax tree, we can simply build an environment to evaluate\nthe syntax tree.`), React.createElement(MDXTag, {\n name: \"blockquote\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `I'm trying to keep myself away from using buzz word, thus I was saying\nthat \"build an environment\". But I cannot stop myself from telling you\nthat we are going to build a `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `virtual machine`), ` now.`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"figure\",\n components: components,\n parentName: \"p\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"figure\",\n props: {\n \"href\": \"/static/b39c2fc7047c623702bd293b8caf6219/917ab/simple-syntaxes.png\"\n }\n }, React.createElement(MDXTag, {\n name: \"img\",\n components: components,\n parentName: \"a\",\n props: {\n \"title\": \"Syntax Tree Examples\",\n \"alt\": \"Syntax Tree Examples\",\n \"src\": \"/static/b39c2fc7047c623702bd293b8caf6219/917ab/simple-syntaxes.png\",\n \"srcSet\": [\"/static/b39c2fc7047c623702bd293b8caf6219/917ab/simple-syntaxes.png 1x\", \"/static/3ac510faf8b4a4da1af9f736ed76d3cf/f4d2f/simple-syntaxes%402x.png 2x\", \"/static/54693ec047d950f70fa7ebe70a960823/0d143/simple-syntaxes%403x.png 3x\"],\n \"loading\": \"lazy\"\n }\n })), `\n `, React.createElement(MDXTag, {\n name: \"figcaption\",\n components: components,\n parentName: \"figure\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"span\",\n components: components,\n parentName: \"figcaption\"\n }, `\n Syntax Tree Examples\n `), `\n `))), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `By taking a look into a syntax tree, we can find that each level of the\nsyntax tree is whether an unary operator node, a binary operator node or\nan operand node. We can abstract the computation of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `NSLayoutConstraint`), `\ninto `, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `small pieces`), ` and ask these three kinds of node to populate the\n`, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `small pieces`), `.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Sounds good. But how to do the abstraction? And how to design those\n`, React.createElement(MDXTag, {\n name: \"strong\",\n components: components,\n parentName: \"p\"\n }, `small pieces`), `?`), React.createElement(MDXTag, {\n name: \"blockquote\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `People who have experience on virtual machine or compiler constructions\nmay know this is a problem related to \"procedure abstraction\" and\n\"instruction set design\". But I don't want to scare readers who may not\nhave enough knowledge about virtual machine or compiler constructions,\nthus I call them \"abstract the computation of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `NSLayoutConstraint`), `\" and\n\"small pieces\" above.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `One more reason why I'm not talking with the term \"procedure abstraction\"\nand \"instruction set design\" is that: though \"instruction set design\" is\nthe most eye-catching term, activities of \"instruction set design\" and\nactivitities of \"procedure abstraction\" affects each other. Leaving these\nterms away from this post can help us understand the essence of the\nentire thing.`)), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `Abstracting NSLayoutConstraint's Initialization`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Since we are gonna support layout guide, the old fashion API`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `convenience init(\n item view1: Any, \n attribute attr1: NSLayoutConstraint.Attribute, \n relatedBy relation: NSLayoutConstraint.Relation, \n toItem view2: Any?, \n attribute attr2: NSLayoutConstraint.Attribute, \n multiplier: CGFloat, \n constant c: CGFloat\n)\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `comes to be an unavailable option for us. You cannot get layout guide work\nwith this API. Yes, I've tried.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Then we may come up with layout anchors.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Yes. This works. My production code makes use of layout anchors. But why\nlayout anchors work?`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `In fact, by checking the documentations we can know that the base class\nof layout anchors `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `NSLayoutAnchor`), ` has a group of API that generates\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `NSLayoutConstraint`), ` instance. If we can get all the arguments of this\ngroup of API in deterministic steps by evaluating syntax tree generated by\nthe \"language\" that we have just designed, then we can abstract a formal\nmodel for this computation progress.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Can we get all the arguments of this group of API in deterministic steps?`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The answer is \"yes\".`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `A Glimpse into Syntax Tree Evaluation`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Before handing out the deterministic steps that compute arguments we need,\nwe have to figure out how Swift syntax tree get evaluated.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `In Swift, syntax trees are evaluated with the order of depth-first\ntraversal. The following figure is the traversal order of syntax\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1 - bunchOfViews`), ` in code block:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `let bunchOfViews = view2 - view3\nview1 | bunchOfViews\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"figure\",\n components: components,\n parentName: \"p\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"figure\",\n props: {\n \"href\": \"/static/c36666410ca86cd3bd070ca45d646ce5/3e14e/syntax-tree-evaluation.png\"\n }\n }, React.createElement(MDXTag, {\n name: \"img\",\n components: components,\n parentName: \"a\",\n props: {\n \"title\": \"Swift Syntax Tree Evaluation\",\n \"alt\": \"Swift Syntax Tree Evaluation\",\n \"src\": \"/static/c36666410ca86cd3bd070ca45d646ce5/3e14e/syntax-tree-evaluation.png\",\n \"srcSet\": [\"/static/c36666410ca86cd3bd070ca45d646ce5/3e14e/syntax-tree-evaluation.png 1x\", \"/static/654e615a1da46893aad32c6da1accb5e/e0728/syntax-tree-evaluation%402x.png 2x\", \"/static/e09dc996de3724cc9510c52ef9c296cf/8ffc1/syntax-tree-evaluation%403x.png 3x\"],\n \"loading\": \"lazy\"\n }\n })), `\n `, React.createElement(MDXTag, {\n name: \"figcaption\",\n components: components,\n parentName: \"figure\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"span\",\n components: components,\n parentName: \"figcaption\"\n }, `\n Swift Syntax Tree Evaluation\n `), `\n `))), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `But even the root node is the first visited node in the whole evaluation\nprocess, since it requires the evaluation result of its left-hand-side\nchild and right-hand-side child to complete the evaluation, it generates\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `NSLayoutConstraint`), ` instance at the last.`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `Abstract NSLayoutConstraint's Computation Procedure`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `By watching the figure of Swift syntax tree evaluation process above, we\ncan know that the node `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1`), ` was evaluated at the second but the\nevaluation result would be used at the last, thus we need a data structure\nto store each node's evaluation result. You probably would come up with\nstack. Yes, I'm using stack in my production code. But I have to mention the\nreason why we need a stack: with a stack, we are able to transform a\nrecursive structure into another recursive form or a degenerated form or an\naggragation of values. Since arguments of the API what we've just picked\nabove can be seen as an aggregation of values, thus stack is what we need.\nYou may have already guessed that I'm going to use stack, but intuition\ndoesn't work all the time. We may face problems rationally.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `With stack, we have to put all the computational resource that is required\nto initialize an `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `NSLayoutConstraint`), ` instance in a single level.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Moreover, we have to keep the stack to memorize the head and tail node of\nthe syntax tree that have been evaluated. Thus there should be a room for\nthe head and tail node for each level of the stack.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Why? Take a look at the following syntax tree:`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"figure\",\n components: components,\n parentName: \"p\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"figure\",\n props: {\n \"href\": \"/static/43900bdf55f69ac199bac9d1957c5230/63496/complicated-syntax-tree.png\"\n }\n }, React.createElement(MDXTag, {\n name: \"img\",\n components: components,\n parentName: \"a\",\n props: {\n \"title\": \"A Complicated Syntax Tree\",\n \"alt\": \"A Complicated Syntax Tree\",\n \"src\": \"/static/43900bdf55f69ac199bac9d1957c5230/63496/complicated-syntax-tree.png\",\n \"srcSet\": [\"/static/43900bdf55f69ac199bac9d1957c5230/63496/complicated-syntax-tree.png 1x\", \"/static/cedb5f118a815de6270c2e3a48a13a7c/770b3/complicated-syntax-tree%402x.png 2x\", \"/static/b8b10469f88221e24dc4a2eecc7b9e6f/afe88/complicated-syntax-tree%403x.png 3x\"],\n \"loading\": \"lazy\"\n }\n })), `\n `, React.createElement(MDXTag, {\n name: \"figcaption\",\n components: components,\n parentName: \"figure\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"span\",\n components: components,\n parentName: \"figcaption\"\n }, `\n A Complicated Syntax Tree\n `), `\n `))), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The syntax tree above was generated by the expression below:`), React.createElement(MDXTag, {\n name: \"pre\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"code\",\n components: components,\n parentName: \"pre\",\n props: {\n \"className\": \"language-swift\"\n }\n }, `let view2_3 = view2 - view3\nlet view2_4 = view2_3 - view4\nview1 | view2_4\n`)), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `When we evaluating the node `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `-`), ` at the second level of the tree (count\nfrom the root), we have to pick `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view3`), `, which is the \"inner\" node of the\ntree, to make an `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `NSLayoutConstraint`), ` instance. Actually, generating\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `NSLayoutConstraint`), ` instances always needs to pick the \"inner\" nodes\nwhich with the perspective of the node being evaluated. But for the root\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `|`), ` node, the \"inner\" node soon comes to be `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view1`), ` and `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `view2`), `. Thus we\nhave to make the stack to memorize the head and tail node of the syntax\ntree that have been evaluated.`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `About the \"Return Value\"`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Yes, we have to design a mechanism to let each node of the syntax tree\nto return the evaluation result.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `I don't want to talk about how a real computer returns value over stack\nframes, because it varies over different size or abstraction patterns (since\ngenerics bring indirection -- which caused by the specialized type is unkown\nduring the compile-time). In Swift world, because all things are safe, which\nmeans you cannot easily access the same piece of memory with different types\nunless by destroying the previous one and initializing another one,\nprocessing data with such a multiple pattern is not a good choice (at least\nfor coding efficiency).`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `We just have to use a local variable in the evaluation context to keep\nthe stack's last pop result (though we also can put it at stack's each\nlevel), then generate instructions to fetch data from that variable. Now\nwe've done the design of the \"return\" mechanism.`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `Building the VM`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The procedure abstraction that we have done shows a significant\ncharacteristic of stack, thus the \"instruction set\" can be designed as\nto manipulate a stack.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `In fact, we just have to let the instructions to do following things:`), React.createElement(MDXTag, {\n name: \"ul\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"li\",\n components: components,\n parentName: \"ul\"\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"li\"\n }, `Fetch views, layout guides, relations, constants and priorities.`)), React.createElement(MDXTag, {\n name: \"li\",\n components: components,\n parentName: \"ul\"\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"li\"\n }, `Generate the information about which anchor to pick.`)), React.createElement(MDXTag, {\n name: \"li\",\n components: components,\n parentName: \"ul\"\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"li\"\n }, `Make constraints.`)), React.createElement(MDXTag, {\n name: \"li\",\n components: components,\n parentName: \"ul\"\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"li\"\n }, `Pop and push the stack.`))), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The complete production code is `, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"p\",\n props: {\n \"href\": \"https://github.com/WeZZard/CTVFL/blob/master/CTVFL/VM/CTVFLOpcode.swift\"\n }\n }, `here`)), React.createElement(MDXTag, {\n name: \"h3\",\n components: components\n }, `Assessment`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `We've done the whole concept of our compile-time-ensured safe VFL.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The question now is what do we gain with it?`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `For Our VFL with Compile-Time Satefy`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The advantage we got here is that a guaranteed of correctness of the syntax.\nSyntaxes like `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `withVFL(H: 4 - view)`), ` or `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `withVFL(H: view - |- 4 - view)`), `\nwould be rejected at compile time.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Then, we've got layout guide worked with our Swift implementation of VFL.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Third, since we're executing instructions which generated by the syntax\ntrees organized at compile time, the total computation complexity is\n`, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `O(N)`), `, which `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `N`), ` is the number of instructions a syntax generated. But\nsince the syntax trees are not constructed as compile-time, we have to\nconstruct the syntax tree at runtime. The good news is that, in my\nproduction code, the syntax tree's type is of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `struct`), `, which means the\nwhole syntax tree is constructed on stack memory but not heap memory.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `In fact, after a whole day of optimizations, the performance of my\nproduction code exceeded all the implementation of existing alternative\nsolutions (includes Cartography and SnapKit), which of course includes the\noriginal VFL. I would place some optimization tips at the end of this\npost.`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `For VFL`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Theoretically, the original VFL may have a bit more advantages on\nperformance over our design -- because the VFL strings can be fetched as C\nstrings, they are loaded directly and there are no initializations shall be\ndone before using them. After that, the UI framework of the targeted\nplatform is ready for parsing the VFL string. Since VFL's grammar is quite\nsimple, building a parser works with time complexity of `, React.createElement(MDXTag, {\n name: \"inlineCode\",\n components: components,\n parentName: \"p\"\n }, `O(N)`), ` is also quite\nsimple. But I don't know the reason why VFL is the slowest solution which\nhelps developers to build Auto Layout constraints.`), React.createElement(MDXTag, {\n name: \"h4\",\n components: components\n }, `Benchmark`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `The following result is measured by building 10k constraints on iPhone X.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"figure\",\n components: components,\n parentName: \"p\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"figure\",\n props: {\n \"href\": \"/static/b122b3d33c60d414e07e0203d6a8885d/e3f32/benchmark-1-view%403x.webp\"\n }\n }, React.createElement(MDXTag, {\n name: \"picture\",\n components: components,\n parentName: \"a\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"source\",\n components: components,\n parentName: \"picture\",\n props: {\n \"src\": \"/static/b122b3d33c60d414e07e0203d6a8885d/0cc25/benchmark-1-view%403x.png\",\n \"srcSet\": [\"/static/b122b3d33c60d414e07e0203d6a8885d/5116e/benchmark-1-view%403x.png 178w\", \"/static/b122b3d33c60d414e07e0203d6a8885d/92f55/benchmark-1-view%403x.png 356w\", \"/static/b122b3d33c60d414e07e0203d6a8885d/0cc25/benchmark-1-view%403x.png 712w\", \"/static/b122b3d33c60d414e07e0203d6a8885d/7ae06/benchmark-1-view%403x.png 1068w\", \"/static/b122b3d33c60d414e07e0203d6a8885d/f0847/benchmark-1-view%403x.png 1125w\"],\n \"sizes\": \"(max-width: 712px) 100vw, 712px\"\n }\n }), React.createElement(MDXTag, {\n name: \"source\",\n components: components,\n parentName: \"picture\",\n props: {\n \"src\": \"/static/b122b3d33c60d414e07e0203d6a8885d/690c8/benchmark-1-view%403x.webp\",\n \"srcSet\": [\"/static/b122b3d33c60d414e07e0203d6a8885d/25c8a/benchmark-1-view%403x.webp 178w\", \"/static/b122b3d33c60d414e07e0203d6a8885d/60698/benchmark-1-view%403x.webp 356w\", \"/static/b122b3d33c60d414e07e0203d6a8885d/690c8/benchmark-1-view%403x.webp 712w\", \"/static/b122b3d33c60d414e07e0203d6a8885d/d7e52/benchmark-1-view%403x.webp 1068w\", \"/static/b122b3d33c60d414e07e0203d6a8885d/e3f32/benchmark-1-view%403x.webp 1125w\"],\n \"sizes\": \"(max-width: 712px) 100vw, 712px\"\n }\n }), `\n `, React.createElement(MDXTag, {\n name: \"img\",\n components: components,\n parentName: \"picture\",\n props: {\n \"src\": \"/static/b122b3d33c60d414e07e0203d6a8885d/e3f32/benchmark-1-view%403x.webp\",\n \"alt\": \"Benchmark 1\",\n \"title\": \"Benchmark with 1 View\",\n \"width\": 712,\n \"height\": 1542,\n \"loading\": \"lazy\"\n }\n }))), `\n `, React.createElement(MDXTag, {\n name: \"figcaption\",\n components: components,\n parentName: \"figure\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"span\",\n components: components,\n parentName: \"figcaption\"\n }, `\n Benchmark with 1 View\n `), `\n `)), `\n`, React.createElement(MDXTag, {\n name: \"figure\",\n components: components,\n parentName: \"p\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"figure\",\n props: {\n \"href\": \"/static/87111c6b420d5b74545638a08ac3603d/e3f32/benchmark-2-views%403x.webp\"\n }\n }, React.createElement(MDXTag, {\n name: \"picture\",\n components: components,\n parentName: \"a\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"source\",\n components: components,\n parentName: \"picture\",\n props: {\n \"src\": \"/static/87111c6b420d5b74545638a08ac3603d/0cc25/benchmark-2-views%403x.png\",\n \"srcSet\": [\"/static/87111c6b420d5b74545638a08ac3603d/5116e/benchmark-2-views%403x.png 178w\", \"/static/87111c6b420d5b74545638a08ac3603d/92f55/benchmark-2-views%403x.png 356w\", \"/static/87111c6b420d5b74545638a08ac3603d/0cc25/benchmark-2-views%403x.png 712w\", \"/static/87111c6b420d5b74545638a08ac3603d/7ae06/benchmark-2-views%403x.png 1068w\", \"/static/87111c6b420d5b74545638a08ac3603d/f0847/benchmark-2-views%403x.png 1125w\"],\n \"sizes\": \"(max-width: 712px) 100vw, 712px\"\n }\n }), React.createElement(MDXTag, {\n name: \"source\",\n components: components,\n parentName: \"picture\",\n props: {\n \"src\": \"/static/87111c6b420d5b74545638a08ac3603d/690c8/benchmark-2-views%403x.webp\",\n \"srcSet\": [\"/static/87111c6b420d5b74545638a08ac3603d/25c8a/benchmark-2-views%403x.webp 178w\", \"/static/87111c6b420d5b74545638a08ac3603d/60698/benchmark-2-views%403x.webp 356w\", \"/static/87111c6b420d5b74545638a08ac3603d/690c8/benchmark-2-views%403x.webp 712w\", \"/static/87111c6b420d5b74545638a08ac3603d/d7e52/benchmark-2-views%403x.webp 1068w\", \"/static/87111c6b420d5b74545638a08ac3603d/e3f32/benchmark-2-views%403x.webp 1125w\"],\n \"sizes\": \"(max-width: 712px) 100vw, 712px\"\n }\n }), `\n `, React.createElement(MDXTag, {\n name: \"img\",\n components: components,\n parentName: \"picture\",\n props: {\n \"src\": \"/static/87111c6b420d5b74545638a08ac3603d/e3f32/benchmark-2-views%403x.webp\",\n \"alt\": \"Benchmark 2\",\n \"title\": \"Benchmark with 2 Views\",\n \"width\": 712,\n \"height\": 1542,\n \"loading\": \"lazy\"\n }\n }))), `\n `, React.createElement(MDXTag, {\n name: \"figcaption\",\n components: components,\n parentName: \"figure\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"span\",\n components: components,\n parentName: \"figcaption\"\n }, `\n Benchmark with 2 Views\n `), `\n `)), `\n`, React.createElement(MDXTag, {\n name: \"figure\",\n components: components,\n parentName: \"p\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"a\",\n components: components,\n parentName: \"figure\",\n props: {\n \"href\": \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/e3f32/benchmark-3-views%403x.webp\"\n }\n }, React.createElement(MDXTag, {\n name: \"picture\",\n components: components,\n parentName: \"a\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"source\",\n components: components,\n parentName: \"picture\",\n props: {\n \"src\": \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/0cc25/benchmark-3-views%403x.png\",\n \"srcSet\": [\"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/5116e/benchmark-3-views%403x.png 178w\", \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/92f55/benchmark-3-views%403x.png 356w\", \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/0cc25/benchmark-3-views%403x.png 712w\", \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/7ae06/benchmark-3-views%403x.png 1068w\", \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/f0847/benchmark-3-views%403x.png 1125w\"],\n \"sizes\": \"(max-width: 712px) 100vw, 712px\"\n }\n }), React.createElement(MDXTag, {\n name: \"source\",\n components: components,\n parentName: \"picture\",\n props: {\n \"src\": \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/690c8/benchmark-3-views%403x.webp\",\n \"srcSet\": [\"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/25c8a/benchmark-3-views%403x.webp 178w\", \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/60698/benchmark-3-views%403x.webp 356w\", \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/690c8/benchmark-3-views%403x.webp 712w\", \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/d7e52/benchmark-3-views%403x.webp 1068w\", \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/e3f32/benchmark-3-views%403x.webp 1125w\"],\n \"sizes\": \"(max-width: 712px) 100vw, 712px\"\n }\n }), `\n `, React.createElement(MDXTag, {\n name: \"img\",\n components: components,\n parentName: \"picture\",\n props: {\n \"src\": \"/static/c98a8fd6a4b9d7c7d3aee25bcbda7542/e3f32/benchmark-3-views%403x.webp\",\n \"alt\": \"Benchmark 3\",\n \"title\": \"Benchmark with 3 Views\",\n \"width\": 712,\n \"height\": 1542,\n \"loading\": \"lazy\"\n }\n }))), `\n `, React.createElement(MDXTag, {\n name: \"figcaption\",\n components: components,\n parentName: \"figure\"\n }, `\n `, React.createElement(MDXTag, {\n name: \"span\",\n components: components,\n parentName: \"figcaption\"\n }, `\n Benchmark with 3 Views\n `), `\n `))), React.createElement(MDXTag, {\n name: \"hr\",\n components: components\n }), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Thank for your reading of this long post. I have to apologize. I lied at\nthe title. This post is totally not a \"glimpse\" into Swift generic\nmeta-programming, it talks about many deep content about computational\ntheories. But I think this post could give a lot of intuitive example for\nthese theories.`), React.createElement(MDXTag, {\n name: \"p\",\n components: components\n }, `Finally, may the generics meta-programming in Swift not come to be a part of\ncontents in iOS engineer interview.`), React.createElement(MDXTag, {\n name: \"blockquote\",\n components: components\n }, React.createElement(MDXTag, {\n name: \"p\",\n components: components,\n parentName: \"blockquote\"\n }, `Revisited at 12nd Sep, 2022.`)));\n }\n\n}\nMDXContent.isMDXComponent = true;","scope":""},"headings":[{"value":"Preface","depth":2},{"value":"Case Study : VFL Compile-Time Safety","depth":2},{"value":"Transforming the Grammar","depth":3},{"value":"Figuring Out the Implementations","depth":3},{"value":"Naïve State Transitioning","depth":3},{"value":"State Transitioning with Multiple States","depth":3},{"value":"Syntax Attribute","depth":4},{"value":"Syntax Boundaries","depth":4},{"value":"Syntax Associativity","depth":4},{"value":"Generating NSLayoutConstraint Instances","depth":3},{"value":"Abstracting NSLayoutConstraint's Initialization","depth":4},{"value":"A Glimpse into Syntax Tree Evaluation","depth":4},{"value":"Abstract NSLayoutConstraint's Computation Procedure","depth":4},{"value":"About the \"Return Value\"","depth":4},{"value":"Building the VM","depth":4},{"value":"Assessment","depth":3},{"value":"For Our VFL with Compile-Time Satefy","depth":4},{"value":"For VFL","depth":4},{"value":"Benchmark","depth":4}]}}},"earlierPostExcerpt":{"slug":"/post/2019/03/use-crontab-to-automate-updates-of-cli-softwares-cac3","title":"Use crontab to Automate Updates of CLI Softwares","subtitle":"","createdTime":"2019-03-24T00:00:00.000Z","tags":["UNIX","crontab","Automation"],"category":"Productivity","file":{"childMdx":{"excerpt":"crontab , an abbreviation of chronic table (periodical time table), is\na task scheduler which schedules tasks in period of time on UNIX systems.\nEach user in UNIX systems have its own \"crontab\". Editing the crontab File By executing crontab -e , you can open the crontab of the user you logged\nin…"}}},"laterPostExcerpt":{"slug":"/post/2019/09/conforming-to-codable-for-associated-value-enums-in-swift-9e3c","title":"Conforming to Codable for Associated Value Enums in Swift","subtitle":"","createdTime":"2019-09-10T00:00:00.000Z","tags":["Swift","Codable","Associated Value Enum"],"category":"Programming","file":{"childMdx":{"excerpt":"Understanding Associated Value Enums Why there are associated value enums in Swift? I mean, why the Swift core\nteam designed associated value enum？ To understand it, firstly, let's take a look at the following example in C: The C struct Device represents a device. The member pointer is an…"}}}},"pageContext":{"postId":"ce1c7301-5889-59f8-821a-d4832b9a64b6","earlierPostId":"134e5703-f8d8-5c94-b7f7-fbe98b44876e","laterPostId":"8e601448-778d-51ca-a66b-b68b06248377"}}