Better Array Inference

[mariari]

With the advent of #22 I've left some holes, namely:

;; src;typechecker;typecheck.lisp
(-> annotate-term-no-binder
    (ir:term-type-manipulation typing-context)
    (values typing-result typing-context))
(defun annotate-term-no-binder (term context)
  "Annotating a term can either end up with the following results:

1. Error
  - If the system is in an invalid state with the binder, an error is
    thrown.

2. `hole-conditions'
  - If the system needs more information to fully determine the type a
    `hole-conditions' is returned.

3. `type-info'
  - If unification is completely successful, then we get back a
    `type-info'"
  (with-accessors ((holes holes) (info hole-info)
                   (dep dependency) (closure typing-closure))
      context
    (match-of ir:term-type-manipulation term
      ....
      ((ir:array-set :arr arr :value value)
       (let ((lookup-val (normal-form-to-type-info value context))
             (lookup-arr (normal-form-to-type-info-not-number-err arr context)))
         (dispatch-case ((lookup-arr lookup-type)
                         (lookup-val lookup-type))
           ;; We will leave some holes, as currently we force the
           ;; submission of the type with an array. This should
           ;; change, and we should be able to understand the length
           ;; of a hole
           ((hole type-info)
            (error "not implemented yet"))
           ((hole hole)
            (error "not implemented yet"))
          ...))))

These holes make it so the user has to give the type of an array when allocating it. If we can omit that information, and get it here then we can have the type of the array be inferred (though length can not be).

[mariari]

This has further issues, as even code like

(defcircuit array-from-data-check-consts ((output (array int 10)))
  (def ((bar (to-array 36)))
    (prld:+ (prld:check 5 (int 32))
            (prld:get bar 0))))

causes issues, as we lack the size information in the hole slot.

Due to this, we can't actually infer the array type, as when we recompute the array type, it will always be an unknown int type. If we had holes which had application, we could submit this back as an equation given the extra hole size in the to-array case