Can Coalton conditions be less wordy?

[jbouwman]

At some point soon, a swank function is going to be seeing coalton conditions that arise during compilation. It will want to return a representation of the messages and spans in the condition to emacs, to support jump-to-error.

Right now, the error printer is strongly oriented towards console output, and contains a mysterious :err field where the real information is stored.

Also, there is also a 'file' reference that is passed into about 120 functions, which is used as the referent for source spans in the printing. The caller -- who will be managing the representation of the condition (sometimes to stdout, sometimes via swank to emacs) surely has this value in hand. Could it be unthreaded?

I would imagine thrown conditions possibly looking more like the following (before, and after):

before:

(lambda (scc file)
  ;; Classes cannot have cyclic superclasses
  (error 'tc:tc-error
         :err (se:source-error
               :span (parser:toplevel-define-class-head-src (first scc))
               :file file
               :message "Cyclic superclasses"
               :primary-note "in class defined here"
               :notes (loop :for class :in (rest scc)
                            :collect (se:make-source-error-note
                                      :type :primary
                                      :span (parser:toplevel-define-class-head-src class)
                                      :message "in class defined here")))))

after:

(lambda (scc)
  ;; Classes cannot have cyclic superclasses
  (error 'tc:tc-error
         :message "Cyclic superclasses"
         :notes (loop :for class :in scc
                      :collect (se:make-note :message "in class defined here"
                                             :span (parser:toplevel-define-class-head-src class)))))

[eliaslfox]

Right now, the error printer is strongly oriented towards console output, and contains a mysterious :err field where the real information is stored.

This is so that the error information is stored on a struct instead of a condition class. We chose structs because struct fields are type checked while condition class slots are not. This leads to better error checking at compile time and runtime.

Also, there is also a 'file' reference that is passed into about 120 functions, which is used as the referent for source spans in the printing. The caller -- who will be managing the representation of the condition (sometimes to stdout, sometimes via swank to emacs) surely has this value in hand. Could it be unthreaded?

It could be. Currently every function that throws a user facing error is passed a file because the file is required to construct a source error. This makes it easier to see which functions can and can't error.