A portable Common Lisp toolkit for building inspectors | Hacker News Reader

A portable Common Lisp toolkit for building inspectors

github.com

57 pointsanonzzzies19 comments

Took me wayyy to long to realize that this is not for people who inspect buildings. https://en.wikipedia.org/wiki/Building_inspection

I was excited to learn how building inspectors were using Common Lisp!

Yup, me too. Actually I needed this comment for it to click, I was reading the src looking for code that might have something to do with beams and buildings.

Time flies like an arrow. Fruit flies like a banana.

I knew it wasn't for inspectors of physical buildings (though that took a minute to accept; I thought it might be a joke), but I could not figure out what kind of buildings it would be. Was it some lisp thing I hadn't heard of? I've been coming back to these comments waiting for someone to explain and it finally hit me: it's for the building of inspectors. Language is weird.

Oh me too. I was hoping for an implementation example of a nice neat little expert system. Maybe a sort of checklist-on-steroids application.

My brain went to the same place. There was just recently a post on Common Lisp being used in a project to aid in mining tunnel evacuations, so, it kinda fit?

I really admired it as a passion project and was a little bit let down by mundane reality.

But then I thought, that’s still pretty cool and I went word tripping for free.

Building inspectors? The guys who complain when you move your toilet 2 feet to the left from where it was on your plan? Those guys use Java 1.0.

I would have figured INTERCAL.

Being able to build multiple different forms of debug inspector that you can use as preferred is a huge feature to me, and trying to provide building blocks so you can build them faster strikes me as an excellent idea.

(I recall once talking to a java dev who considered perl a complete disaster for debugging because ... whatever tool he'd picked to help him produced debug output that suited neither the codebase nor his brain, and the java code he was working with at least managed representations that suited the codebase ... meanwhile, I often get frustrated at how tricky I found it to convince java to let me have multiple different debug stringifications ... such is life ;)

This just talks to the heritage of Lisp.

There are certainly other interactive languages, there are other interactive object oriented languages, but few rose to the level of Lisp when it became not just the systems programming language of specialized operating systems, but also the command shell and development tool for such systems.

It was also during a time where keyboard interaction was still the primary means of interface. Even with the creation of the Lisp machines and their large graphic displays, those displays were dominated by "terminal" windows.

Java has "toString". But Java has no heritage of interacting with it via a terminal interface. In the modern world of graphic displays, windowed environments, and IDEs, those larger tools expose the objects of the JVM (which are made quite transparent by the debugger infrastructure). Outside of "toString", there's not much call for language level specialized handling. IDEs did all of the heavy lifting.

I, too, have done things like "toDebugString" or something equivalent, that I could put in a watch expression in the debugger. And, that was "enough".

In Lisp, Lisp was "the tool", it was "the debugger", there wasn't really a separate artifact peering into the image. So, it required the ability to do all of that in and of itself.

A few years later, and Lisp likely would not have done this. Even Smalltalk doesn't do this. Its inspector is a generic tool. But ST was mostly a GUI based system. And, sure, you can just override STs inspect method. I'm guessing most don't.

> It was also during a time where keyboard interaction was still the primary means of interface. Even with the creation of the Lisp machines and their large graphic displays, those displays were dominated by "terminal" windows.

In Symbolics Genera a Lisp Listener (the window which runs a combination of a REPL and a command line interpreter) is a full graphics window with the same drawing capabilities as PostScript. It's also a command interpreter taking Lisp objects as arguments to commands.

The UI isn't using much direct manipulation with the mouse (like dragging a file between folder windows), though for example in the graphics editor one can do that for graphics objects. One also interacts with graphical scrollbars. Much of the UI is based on displaying textual and/or graphical objects AND running commands on them. Application windows all have a (often visible) command interpreter, where interacting with objects is done via commands on objects (and not only on text), using textual commands, mouse gestures or command menus.

The Listener (as do other applications) also records all output and keeps the relationship with the objects which a drawn/printed.

Thus the Genera UI does not use "toString", but calls PRESENT (or similar), a function which outputs Lisp objects in various ways, records the output (text and graphics) and keeps the relationship between object and output. Thus the Listener is not only a graphical stream, but also a graphical object store (-> it stores all output using a complex object-oriented framework). (similar -> McCLIM -> https://mcclim.common-lisp.dev -> example for tools/apps https://mcclim.common-lisp.dev/excite.html ).

One can return/print a data structure in the Listener and then one can point with the mouse at sub-objects and run commands on them (like 'describe'). This makes a separate inspector mostly unnecessary, though there is a inspector window. As there is a debugger window with backtrace, code display, etc. There is also a PEEK window, which is used to inspect things in the OS: Windows, File Systems, Memory, Processes, Network, ...

The Glamorous Toolkit crew have been doing some amazing stuff in terms of having multiple heavily custom type-specialised inspectors, and while being ST based they're much more GUI focused than REPL focused I think it's not unreasonable to say it's the same spirit, but ST style rather than Lisp style.

(for those following along at home, Interlisp was a work of art and I cached a couple of the relevant manuals under https://trout.me.uk/lisp/ so I didn't keep having to go find them yet again to re-read for inspiration)

I reuse SLIME's inspector for other Lisps. This is Elisp, for Elisp:

    (defun inspect-in-slime ()
      (interactive)
      (slime-inspect
       (format "%S" `',(eval
                        (elisp--preceding-sexp)))))
    
    (add-hook 'lisp-interaction-mode-hook
              (lambda ()
                (local-set-key (kbd "C-c I") #'inspect-in-slime)))

You only cover a subset of your Lisp with this (without additional work), but it's a useful* subset and you get it essentially for free, for anything that "looks close enough" like a Lisp. And you get SLIME's polished, feature-rich inspection TUI, also for free.

*(Particularly in Elisp, since Emacs uses lots of large cons-cell data structures that are very unpleasant to read!)

I wish ielm had presentations like SLIME ...

It would be interesting to see if there are any useful integrations possible between this and 'Clouseau', the Inspector provided by McCLIM (McCLIM being a somewhat idiosyncratic UI toolkit implemented in pure Common Lisp). Years ago I'd extended Clouseau to do implement some custom visualizations of data structures in a work project, where I recall it was a relatively straightforward matter of specializing certain generic functions, but no longer recall the details.

It would be a service to non-Lisp users if someone could describe why this matters. Is this debug pretty-printing?

From the webpage:

> `trivial-inspect` exposes a set of utils useful in building inspectors akin to standard `inspect` and `describe`.

Here is the documentation for `inspect`, <https://www.lispworks.com/documentation/HyperSpec/Body/f_ins...> and `describe`, <https://www.lispworks.com/documentation/HyperSpec/Body/f_des...>.

I’ll quote the relevant bits here. First `describe`:

> `describe` displays information about object to stream.

> For example, `describe` of a symbol might show the symbol's value, its definition, and each of its properties. `describe` of a float might show the number's internal representation in a way that is useful for tracking down round-off errors. In all cases, however, the nature and format of the output of `describe` is implementation-dependent.

> `describe` can describe something that it finds inside the object; in such cases, a notational device such as increased indentation or positioning in a table is typically used in order to visually distinguish such recursive descriptions from descriptions of the argument object.

And finally `inspect`:

> `inspect` is an interactive version of `describe`. The nature of the interaction is implementation-dependent, but the purpose of `inspect` is to make it easy to wander through a data structure, examining and modifying parts of it.

Essentially these are built–in methods of introspection. One particularly nice thing about them is that `describe` calls a generic function named `describe-object`. Because this is a generic function, you can add specialized methods to it for your own classes. This lets you customize the output to best suit your own needs.

Adding to what db48x said, the CL standard dictates what goes into the "COMMON-LISP" package (abbreviated "CL"), but also allows implementation specific additions as long as they're put in their own packages. Over time the different implementations have added similar functionality but with different APIs and in different packages. The "trivial-" prefix is a naming convention for third party (not a compiler vendor) packages that wrap those implementation specific system libraries to provide the same API everywhere. Usually these are implemented as macros or functions simple enough to get inlined and not have much overhead.

In this case, the standard only requires high level functions "inspect" and "describe", but most implementations have packages (SBCL provides a "sb-introspect") to get more detail.

It's generally done for things like threading, garbage collection settings, CFFI, etc. that would be difficult to implement outside of the compiler or runtime.

Reply on news.ycombinator.com