-
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathnotes.html
169 lines (132 loc) · 7.8 KB
/
notes.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
<!-- goal: generalize mathquill.com functionality-->
<!-- implementation note: it would be great if slots are lightweight enough that they can be
extensively composed. -->
<!-- tangential idea: A web3 code sharing slot and a versioning slot e.g.
<<CODESHARE (inputs:: package name) (outputs:: nothin (side effect))>>
<<VERSIONER [history tree editor / tagger?]>>
-->
<!-- model idea comment: transformers can be implemented as slots with access to their slot outputs -->
<!-- model idea comment: strings are a workaround to normal slots for simplicity of rendering -->
<!-- model: nested things with state that compile to js (executable) e.g.
<<HTML EDITOR>>
<<TIMELINE EDITOR (outputs:: some sort of timeline?)>>
<<VOICE RECORDER (outputs:: external sound file, promise for loading that file)>->
<<HISTORY RECORDER (inputs:: code from slot) (outputs:: diffs array)>>
<<MARKDOWN EDITOR (outputs:: a comment)>>
function hello() {
const color = <<COLOR EDITOR (outputs:: rgba strings)>>
const graph = <<GRAPH EDITOR (outputs:: adjacency 2dArrays)>>
const isGood = <<CHECKBOX (outputs:: true or false)>>
const aVec3 = <<VECTOR EDITOR (outputs:: vector contructor)>>
const bVec3 = <<VECTOR EDITOR (outputs:: vector contructor)>>
const rVec3 = <<LINEAR ALG OPERATIONS bVec3 + aVec3 (outputs:: function to add two vectors)>>
}
<<MARKDOWN EDITOR (outputs:: a comment)>>
-->
<script>
// question: how to represent the caret being "inside" a slot
// - let's think of a character as an example:
// - characters do not have an "inside": the caret can only be before or after a character.
// - If the start of the caret was before a character, and the end was after that character,
// then that could be considered inside. BUT then deleting would intuitively delete that
// entire character rather than the thing within it.
// - Given that counterexample to the before/after idea, I think there needs to be a way to
// recursively address a caret.
// - Should it be possible for the caret start to be inside a slot while the caret's end is
// outside? YES, highting half a vector and half the equation it is in will not be possible.
// - Caret start and end addresses can both use the same recursive addressing scheme, just
// with different addresses.
// - It should be possible to look at a caret address and not need to know the size of a
// slot's "caret space" (the number of caret addresses within that slot, and the slots within
// it) which the caret is inside in order to tell where the start / end address of that slot
// is.
// - So, a proposal for the caret address scheme is: 10.7.0 meaning that, in the slot
// at 10, there is a slot at 7, and in that slot the cursor is at 0. More meaningfully the
// the slot at 10 is between 10 and 11, just like the character "a" in the string "ab" is in
// between caret 0 and caret 1 (using traditional string caret addressing).
// - A caveat of the above addressing scheme is that it doesn't include the widths of
// slots. Could this cause issues when highlighting? Well, the ordering of addresses is not a
// problem: addressess are unambiguously ordered e.g. 10.7.0 > 10.5.99 < 11 < 100.13.69
// - Another caveat is that this may result in slots having to manage their own addressing. I
// would like slots to be able to easy ignore addressing. Slot address widths would affect how
// the left and right arrow behave: if a caret is at the end of a slot and the right arrow is
// pressed, then the caret would move out of the slot e.g. 46.9 -> right arrow -> 47. Slots
// should be able to prevent left/right arrow navigation out of the slot without setting a
// silly width.
// - Implementation vs notation note: 44.69.7.0.1101 = [44, 69, 8, 0, 1101].
// - Should slots be allowed to define their own addressing scheme? 2D slots would need a
// different addressing scheme.
// - Yes actually i think slots should handle their own addressing. But then how does copy&paste
// work?
//
class ExampleElement extends HTMLElement {
constructor() {
// Always call super first in constructor
super();
// Create a shadow root
this.attachShadow({ mode: 'open' });
this.shadowRoot.append(document.createTextNode('hello!'));
this.style.color = 'blue';
}
}
customElements.define('example-element', ExampleElement);
// dragging editors?
// enter:
// - focus parent and let keydown through (default)
// - this.parentEditor.focus({ event: 'enter' })
// enter on empty, backspace on empty:
// - focus parent and request that the parent editor deletes this
// leave left and right:
// - should keyboard automatically leave the element if it does not change the state?
// - no, caret is not part of state so this wouldn't even work on the text editor.
// focused
// highlighted - highlighted by the parent editor.
</script>
<!--
Aug 17 2020
What I need right now:
1. A way to save and load editor states
2. A way to define custom functionality of an operator e.g. `syntax a + b => [a[0]+b[0], a[1]+b[1]];`
so that I can actually write something (I want to write the graph editor) using polytope.
Potential solutions:
1.a. delimitter-based serialization e.g. `a^(Math(2))` serializes to a /* polytope:math-exp:start */ ** 2 /* polytope:math-exp:end */`
1.b. analytic serialization e.g. I tell polytope that `a^2` should have the structure `a^(Math(2))` when it is loaded.
2.a. hardcode a + b as `plus(a, b)` for now and let the user define the plus function.
2.b. implement a type hierarchy so that num + num => one thing while vec + vec goes to another.
Problems with potential solutions:
1.a.i. gross output javascript.
1.a.ii. polytope would not support analytic / automatic editor-ization. All editors must be manually inserted by the user.
1.b.i. requires parsing of javascript.
1.b.ii. may not succeed to parse partial/broken javascript.
1.b.iii. requires some way to specify which part of the javascript AST should be converted to polytope structures and how.
2.a.i. User has to do everything (including boilerplate for all the math functions).
2.a.ii. polytope doesn't do any heavy lifting when it comes to operator overloading. There is useful nested editor info that polytope could take advantage of for typing.
2.b.i. type hierarchy design is unclear and requires research.
2.b.ii. increases complexity.
2.b.iii. strays away from the current core ideas of polytope.
2.b.iv. may requires substantial time to implement.
Based off this analysis, 1.a. and 2.a. should serve my needs with low short-term downside. It
would be cool to revisit these problems in the future.
Before I leave these ideas and move onto implementation, it would be very cool to implement
an editor / syntax around 2.b... something like (pattern matching for math +):
```polytope
editor "+" math((vec(a) + vec(b)) => vecAdd(a, b);
editor "+" math(math(a) + math(b)) => a + b;
```
explanation: "+" is the key you press on your keyboard to construct the editor;
math(math(a) + math(b)) represents a math editor containing an addition of two math editors and
what the output should be.
-->
<!--
Nov 5.
Should use AST subtree matching predicates instead of my primitive stringToEditorBuilder paren matching
and paren interior validating/parsing functions.
-->
<!--
Nov 15.
Goal: give bidirectional editors output so they can more easily be chained
-->
<!--
Nov 19.
https://2ality.com/2019/10/eval-via-import.html fixing up file component
-->