11 ms·

> it’s lists, hash-tables, strings, vectors, and all the types of things programmers manipulate every day. Except the lisps with good error messages don't real

by xscott 6y ago

> it’s lists, hash-tables, strings, vectors, and all the types of things programmers manipulate every day. Except the lisps with good error messages don't really use those things without tagging on the file and line number where they came from. You end up working with "syntax objects" or something instead.

fiddlerwoaroof 6y ago
Racket does this, I personally have no issues with the error messages in Common Lisp implementations, that generally implement this sort of thing by generating special source forms that are just lists wrapping other parts of the program.
phoe-krk 6y ago
Common Lisp does that. There is a portability library that provides an implementation-independent interface to that functionality for Lisp programmers: https://github.com/scymtym/trivial-with-current-source-form https://github.com/scymtym/trivial-with-current-source-form
kazinator 6y ago
TXR Lisp keeps a weak hash table which associates objects in the syntax with file/line information, without changing their representation in any way. There is no need for ugly, cumbersome syntax objects that destroy Lisp. Whether or not the recording of source loc info is enabled is controlled by a special variable. It is disabled by default, because you probably don't want that overhead if you're calling the reader for reams of data. Functions like compile-file and load enable it locally. To take advantage of the info for error reporting in a user defined macro, you can simply do this: (defmacro mymacro (:form f arg1 arg2 ...) ;; get the form using :form (when (somehow-no-good arg1) ;; something wrong with arguments (compile-error f "first argument ~s is no good!" arg1)) ...) You get an error which mentions mymacro, and the location. (foo.lisp:10) mymacro: first argument 42 is no good!
- xscott 6y ago
  This is interesting and clever - thank you for sharing it. However, it seems like the hash table would work on either the address or the shape of the code, and in either case you could build a pathological case which would break it. It's probably a really nice solution for the common/realistic case though.

by xscott 6y ago

fiddlerwoaroof 6y ago

Racket does this, I personally have no issues with the error messages in Common Lisp implementations, that generally implement this sort of thing by generating special source forms that are just lists wrapping other parts of the program.

phoe-krk 6y ago

Common Lisp does that. There is a portability library that provides an implementation-independent interface to that functionality for Lisp programmers: https://github.com/scymtym/trivial-with-current-source-form https://github.com/scymtym/trivial-with-current-source-form

kazinator 6y ago

TXR Lisp keeps a weak hash table which associates objects in the syntax with file/line information, without changing their representation in any way. There is no need for ugly, cumbersome syntax objects that destroy Lisp. Whether or not the recording of source loc info is enabled is controlled by a special variable. It is disabled by default, because you probably don't want that overhead if you're calling the reader for reams of data. Functions like compile-file and load enable it locally. To take advantage of the info for error reporting in a user defined macro, you can simply do this: (defmacro mymacro (:form f arg1 arg2 ...) ;; get the form using :form (when (somehow-no-good arg1) ;; something wrong with arguments (compile-error f "first argument ~s is no good!" arg1)) ...) You get an error which mentions mymacro, and the location. (foo.lisp:10) mymacro: first argument 42 is no good!

xscott 6y ago
This is interesting and clever - thank you for sharing it. However, it seems like the hash table would work on either the address or the shape of the code, and in either case you could build a pathological case which would break it. It's probably a really nice solution for the common/realistic case though.