[HN Gopher] A portable Common Lisp toolkit for building inspectors
___________________________________________________________________
A portable Common Lisp toolkit for building inspectors
Author : anonzzzies
Score : 54 points
Date : 2024-05-03 10:43 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| NegativeLatency wrote:
| 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!
| arittr wrote:
| 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.
| pfdietz wrote:
| Time flies like an arrow. Fruit flies like a banana.
| asgraham wrote:
| 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.
| buescher wrote:
| 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.
| dleink wrote:
| 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?
| brudgers wrote:
| 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.
| jujube3 wrote:
| 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.
| akira2501 wrote:
| I would have figured INTERCAL.
| mst wrote:
| 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 ;)
| whartung wrote:
| 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.
| lispm wrote:
| > 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, ...
| mst wrote:
| 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)
| KerrAvon wrote:
| It would be a service to non-Lisp users if someone could describe
| why this matters. Is this debug pretty-printing?
| db48x wrote:
| 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`, <ht
| tps://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.
| jlarocco wrote:
| 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.
| perihelions wrote:
| 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!)
| ahefner wrote:
| 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.
___________________________________________________________________
(page generated 2024-05-04 23:02 UTC)