Skip to content

Latest commit

 

History

History
242 lines (210 loc) · 7.01 KB

TODO.md

File metadata and controls

242 lines (210 loc) · 7.01 KB

TODO

Demos

  1. Tile design – gallery/5_tile_design.l1
    • needed functions:
      1. Tile
      2. GetDigit
  2. Other
    • Iota
    • RankUp, RankDown
    • ArgMin, ArgMax
    • StochasticGradientDescent
    • Gradient
    • Flow

Language

  • Operators for tensor
    • equal = ==
    • not equal !=
    • less than <
    • more than >
    • less than or equal <=
    • more than or equal >=

Wholeness

  1. Prelude
    • because many things can be written in L1
  2. Traditional visualizations
    • Plots
      • What is the best plotting library?
        • should be able to continuously redraw itself with new data
      • What does TensorBoard use?
      • line, bar, scatter, ..?
      • BarChart [0 1 2 3 4 5]
      • LineChart [0 1 2 3 4 5]
      • ScatterPlot [0 0, 1 1, 2 2, 3 3] or [0 1 2 3, 0 1 2 3]
      • BarChart [0 1 2, 3 4 5]
      • Chart { ... }
  3. Router
    • Must be hierarchical
      • I don't know what that means right now.
      • Can target part of the "notebook"?
    • kind of relevant – import from other notebooks
      • :: #L1.#myNotebook.#rev111.functionOfInterest
      • #L1 object will do the loading (maybe different name?)
      • "rev" as from "revision" is unique version of the notebook
        • content-hashes would be awesome, but ugly
        • automatic numbering?
        • user-defined version?
  4. How to directly compare two tensors?
    • `a: Zeros [10], b: Ones [10]
  5. How to visualize high-rank tensors?
    • 1D, 2D slices?

UX

  1. When there is a error, selection is not visible
    • clashes with more than one error on the line
      • grouping errors by line?
  2. Code completion provider which takes rootEnvironment as the source
  3. History
    • what must be preserved (in state obj):
      • scrollOffset in board
      • scrollOffset in editor
      • cursor position in editor
  4. working links in Markdown
  5. Broken visual cue for scrolling the board
  6. Correspondence between code and visualization
    • Focus
      • What part of visualization was generated by which part of the code?
      • What code generates which part of the visualization?
    • mockup would help and can be a good start

Crazy

  1. silent assignment folded by default?
  2. Markdown for error messages
  3. KaTeX for Markdown
    • would be super-convenient
  4. Name resolution
    • Capitalized names could be resolved from root
      • or non-overideable through #meta
    • Capitalized names could be resolved by abbreviations (as in Moniel)
  5. Tensors should be callable – indexing
    • a: [1 2 3], c: a[0] ; c = 1 :D
    • this way the second tensor is an address to the first one
    • source: [1 2, 3 4], indices: [0 0, 1 1], result: source(indices) ; result = [1 4]
    • this is the real shit!
    • (and @ can stay for matmul, yay!)
  6. #render (because of that "Can I create AI in HTML?" meme)
; mu: {
;     #render: props => (
;         <div>
;             <span>{props.name}</span>
;             <span>{props.surname}</span>
;         </div>
;     )
; }
mu: {
    #state: {
        name: "John"
        surname: "Doe"
    }
    #render: props => (
        {
            tag: "div"
            content: {
                child1: {
                    tag: "span"
                    content: props.name
                }
                child2: {
                    tag: "span"
                    content: props.surname
                }
            }
        }
    )
    #call: a => #render #state 
}

hu: mu!

Random

  • ::Self should be ::RTFM
  • allow ! and () as a lambda argument?
  • :: with expression
    • eliminates cognitive friction
    • empty string as a key
      • (as a shorthand for #valueOf or #return?)
      • user cannot use it before naming it – good
      • is forced to have only one non-named prop – good

Bugs

* rendering an <Issue /> is leaking because Monaco does not notify DOMNode removal
    * report issue in Monaco GitHub?

Open questions

How to mutate an existing object?

  1. Is it even necessary?
  2. Should it be allowed?
  3. When is it a good idea?

What about this?

Counter: {
    i: 0
    increaseBy: x => {
        i: i + x
        increaseBy: x => { ; can't just ::increaseBy because of the wrong closure
            i: i + x
        }
    }
}

Counter: Counter.increaseBy 7
Counter: Counter.increaseBy 2
Counter: Counter.increaseBy 1 ; does not scale

; also, if Counter is shared, it won't work

State object

One route may be having an explicit state object inside the normal object. State object could be mutated. However, there also needs to be a way to access parent/super/prototype object somehow...

Counter: {
    #state: {
        i: 0
    }
    increaseBy: x => {
        #state.i: #state.i + x
    }
}

mu1: Counter.increaseBy 3
mu2: Counter.increaseBy 3

Another approach:

Counter: {
    #state: {
        i: 0
        ; internal fn
        ; #call: newState => ()
    }
    increaseBy: x => #state {
        i: #state.i + x
    }
}

mu1: Counter.increaseBy 3
mu2: Counter.increaseBy 3
:: Counter.#state.i

So far, there should be a way to modify super/proto object. But then L1 cease to be pure. Object should not be changed directly from outside by force. But it should be able to change itself when asked nicely.

a: {
    b: 22
}
; a.b: 23
a: a.#mutate {
    b: 23
}

; looks really awful

Links