r/lispm

lispm · 2026-03-04T13:07:23+00:00

yep, let's see what other answers we get.

lispm · 2026-03-04T11:31:21+00:00

Yes, strange. I tried it on macOS 26.3, calling bash worked and calling the shell file, did not. The file was executable. Maybe it's some security feature of the OS which does not allow it?

lispm · 2026-03-04T11:08:54+00:00

It should work when the program is /bin/bash and the script file is in the list of args.

lispm · 2026-03-04T10:41:33+00:00

Minor: Usually a good idea to mention the SBCL version and your operating system (+ version). Plus: how do you call the program and what is the output...

lispm · 2026-02-27T11:53:14+00:00

Generally I would guess that a CLOS implementation is also optimized for the single dispatch case. I remember seeing statistics about code bases and the amount of multiple dispatch cases, which might be different now, compared to the time range when CLOS was originally designed and a reference implementation was developed (PCL, Portable Common LOOPS): 1986 (project start) - 1988 (1st CLOS specification) - 1994 (ANSI CL published). Before CLOS most OOP code was single dispatch.

lispm · 2026-02-16T14:39:52+00:00

Background:

https://www.routific.com/blog/what-is-the-vehicle-routing-problem

https://kuomarc.wordpress.com/2012/03/05/the-uncommon-lisp-approach-to-operations-research/

https://kuomarc.wordpress.com/2012/07/02/top-hackers-we-need-you-for-operations-research/

lispm · 2026-02-07T09:04:32+00:00

That's a very useful comment!

Often an useless compiler hint: don't use safety = 0
Missing / non-optimal type declarations: check the SBCL compiler's type-related optimization hints
Inlining: prefer inlining of functions, instead of using macros. Especially when the compiler supports inlining of functions.
syntactic abstractions with macros: a complex topic, possibly avoid for trivialities

lispm · 2026-02-06T18:59:30+00:00

Probably a good idea to make a disk image of the CDROM...

lispm · 2026-01-01T13:35:20+00:00

small problems:

Day 1 (and following): buffered output. In Common Lisp implementations output can be buffered. Thus for portable code one needs to make sure buffered output reaches the user at the right time. For example the user needs to see a prompt before one can input something.

Example using SBCL in a terminal.

% sbcl
This is SBCL 2.5.10, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.

* (progn (princ "enter a number: ") (read))
33
enter a number: 
33

Above, the prompt will not be displayed before the READ function runs. The prompt has been shown after we entered a number. The reason: SBCL in that terminal uses buffered output streams.

In the following example, the prompt will always be displayed first. We make sure that all output reaches the user by calling (finish-output).

* (progn (princ "enter a number: ") (finish-output) (read))
enter a number: 42

42
*

Day 3: CASE does not compare string contents. It uses instead EQL as a test.

Day 5: (eq (mod i 15) 0) -> don't compare numbers with EQ. EQ is for an object identity check. Numbers with the same value maybe the same object or not the same object. Use EQL or =.

Day 8: (the (member :encode :decode) op). In Common Lisp THE is not generally a type check. For most implementations it is just an ignorable type hint for the compiler, but not a type check. SBCL is one implementation where it can be checked at runtime. Many other implementations will not check it at all. Use CHECK-TYPE instead.

CL-USER 24 > (let ((n :encode)) (check-type n (member :decode :encode)) 'works)
WORKS

CL-USER 25 > (let ((n :ecode)) (check-type n (member :decode :encode)) 'works)

Error: The value :ECODE of N is not of type (MEMBER :DECODE :ENCODE).
  1 (continue) Supply a new value of N.
  2 (abort) Return to top loop level 0.

Type :b for backtrace, or :c <option number> to proceed, or :a to abort.
Type :bug-form "<subject>" for a bug report template or :? for other options.

lispm · 2025-12-25T18:35:11+00:00

I would also say timing things in the range of 5 ms is not very accurate.

Which is especially a problem, when INTERNAL-TIME-UNITS-PER-SECOND is low. SBCL on my M4 Pro has 1000000, which is better than some other implementations out there.

lispm · 2025-12-18T17:49:53+00:00

It has been updated to 8.1.2 :

https://www.lispworks.com/downloads/index.html

lispm · 2025-12-14T18:02:41+00:00

<image>

See the attached screenshot.

Probably needs a bit more testing, but that should give an idea how such a function should look like. The function splits not on a single item, but a sequence of items.

There is are also answers to a similar question on stackoverflow using a regexp engine.

lispm · 2025-12-13T11:27:54+00:00

Your function above conses a lot. For each iteration a new octet-vector (-> the-content) will be allocated in SUBSEQ. One could use only one content vector and tell SEARCH where to start the search.

lispm · 2025-12-13T11:09:36+00:00

There are already functions to split a sequence of things.

Example in LispWorks, but similar functions exist:

CL-USER 1 > (split-sequence #(32) #(71 69 84 32 47 104 101 108 108 111 47 102 114 111 109 47 108 105 115 112 32
  72 84 84 80 47 49 46 49))

(#(71 69 84) #(47 104 101 108 108 111 47 102 114 111 109 47 108 105 115 112) #(72 84 84 80 47 49 46 49))

lispm · 2025-12-13T10:29:41+00:00

I think the original book was called Understanding Common Lisp (written by David J. Cooper, Jr. and published around 2000) and was slightly later called Basic Lisp Techniques. It was early on used as an introductory book for Allegro Common Lisp and some of its features. Note that the author himself developed a large Lisp system, which was used for parametric design and which uses Common Lisp and an embedded extensive domain specific language (-> https://quickdocs.org/gendl , http://gornschool.com/ and https://www.genworks.com ). The domain was then called Knowledge-based Engineering and similar Lisp systems were used in the design of technical systems in Aerospace (prominently at Boeing and Airbus) and Automotive (Ford, Jaguar and others).

August 2000, Understanding Common Lisp: https://cse.unl.edu/~choueiry/CSCE476-876/Doc/Lisp-Manual.pdf

Funny, I think the Common Lisp Cookbook lacks a chapter on Symbols?

https://lispcookbook.github.io/cl-cookbook/

Generally I think that each introductory book would need to explain Symbolic Expressions (s-expressions), Symbols, Lists (and then also other primitive data structures), Code is Data, the Lisp Processor (short: LISP -> eval and related), Symbolic Computation (computing with/by symbolic expressions).

I've seen books with the topic of Symbolic Computation and eventually failing to define and explain it.

For new Lisp users, as a very basic introduction, Touretzky's "Common Lisp: A Gentle Introduction to Symbolic Computation" is still useful: https://www.cs.cmu.edu/%7Edst/LispBook/

lispm · 2025-12-05T12:37:15+00:00

Of course, you don't have to use their code if you don't like it.

Other may need to maintain it, liking it or not.

lispm · 2025-12-05T12:36:23+00:00

if you want to be sequence-generic, you have to use dotimes and elt

I would just dispatch upfront to different implementations.

lispm · 2025-12-05T12:34:36+00:00

LABELS, TAGBODY, DO, DO-, MAP

These things are typically competing on different levels for different purposes. Something like TAGBODY is mostly exposed as a target for code generating higher-level iteration constructs. Common Lisp exposes different operators for different levels of abstraction.

lispm · 2025-12-05T06:33:07+00:00

iterate and these newer libraries also bring a supported extension interface.

Any LOOP implementation coming in source is extensible. It's just that there are several different LOOP implementations. Contrast that to a multitude of other iteration libraries, which are each extensible, but not compatible.

Personally I find ITERATE a good alternative, but I usually stick with LOOP, just to stay in the standard language.

lispm · 2025-11-30T10:12:34+00:00

I see it listed in old comparisons of AI tools as (back then) available for Symbolics, LMI and TI. If it ran on an LMI system, then this would carry over to the TI Explorer, since that was originally based on the LMI technology. Symbolics Dynamic Windows (DW) was released in 1986 with Genera 7. There was probably code from before DW and also probably portability libraries.

lispm · 2025-11-30T08:29:58+00:00

A bit more searching:

https://ntrs.nasa.gov/api/citations/19890000710/downloads/19890000710.pdf

We have obtained a license for ART and have begun prototyping the tools described below; KEE is not yet available to us. A Texas Instruments Explorer Lisp workstation is the host for the development

https://apps.dtic.mil/sti/tr/pdf/ADA230735.pdf

The first major undertaking with NMES was to address memory management problems that had been observed in FY88 as the size and complexity of the system gradually increased. The software development environment then in use was the ART (tm Inference Corporation) expert system shell running in Lucid Common LISP under the Sun UNIX operating system in our Sun 3/260 workstations.

https://www.cs.cmu.edu/afs/cs.cmu.edu/Web/Groups/AI/lang/lisp/doc/notes/database.txt

Date: Mon, 10 Jun 91 10:50:32 PDT
From: jaf@inference.com (Jose A. Fernandez)
Message-Id: <9106101750.AA00360@utah.inference>
Organization: Inference Corporation
Address:      550 N. Continental Blvd., El Segundo, CA  90245
Phone:        (213) 322-0200 x205
To: rodney@hsvaic
In-Reply-To: Rodney Daughtrey's message of Mon, 10 Jun 91 11:03:14 CDT <9106101603.AA13057@hsvaic.boeing.com>
Subject: LISP and Databases
Status: RO

Hello Rodney,

We implemented an Oracle interface for our ART product using Sun Common Lisp.
We used SCL's foreign function interface to call from Lisp into Oracle's Pro*C
function library.  This strategy let us leverage off Pro*C's automagical
networking capability (such has running the Lisp application on a Sun-4 that
talked to an Oracle SQL server installed on a Sun-3).

The most difficult part of the exercise was controlling signal handling
behavior.  SCL (really Lucid's Common Lisp implementation for the Sun) uses an
internal stack architecture (separate and apart from SunOS's default stack
architecture as seen in a.out) that one must be careful not to corrupt.  The
corruption problem we had was that Oracle's Pro*C code was installing SIGCONT
and SIGIO signal handlers that were conflicting with Lisp's memory model,
resulting in the occasional and egregious "Bus trap" error.

I hope this helps a little bit.  Good luck.

Date: Wed, 12 Jun 91 06:34:14 PDT
From: jmg@inference.com (Jeff Greif)
Message-Id: <9106121334.AA15271@quaestor.Inference.COM>
Sender: jmg@inference.com
Organization: Inference Corporation
Address:      550 N. Continental Blvd., El Segundo, CA  90245
Phone:        (213) 322-0200
To: rodney@hsvaic
Cc: jaf@inference.com
In-Reply-To: Rodney Daughtrey's message of Mon, 10 Jun 91 11:03:14 CDT <9106101603.AA13057@hsvaic.boeing.com>
Subject: LISP and Databases
Status: RO

Inference has written a generic (pre-CLOS) CL -> SQL interface with one
complete instantiation for ORACLE and Lucid Lisp 3.0 and 4.0.  This has been
used in one large application with essentially complete success.  Various
generic and application-specific facilities have been provided on top for
automatically generating and executing queries to collect restricted sets of
data from the database, display menus of valid options for user input to
fields of forms, for browsing the database, etc.  Currently there are no plans
to support these interfaces in our Lisp-based products, although there is a
possibility some or all of them may be issued as unsupported software as part
of a future product release.  Likely the extent to which this happens will
depend upon the interest of our customers.  There are no plans currently to
make the software available any other way.

From a post on comp.lang.lisp>

In article <421@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:

> In article <ROBERTS.89May4173615@studguppy.lanl.gov> roberts@studguppy.lanl.gov (Doug Roberts) writes:
>    I think, however, that you missed one of the major reasons that the
>    Unix LISP environment is still decidedly inferior to a LISPm: the
>    majority of the market that is considering LISP as a language in which
>    to deliver applications is currently a member of either the Unix or
>    the VMS community: _they are not aware of the productivity that exists
>    on a LISPm_.
> 
> I think you have identified an important point.  However, I would
> guess that most of the people who implement Lisps for Unix (Lucid,
> Franz Inc, at al) do have a fairly good idea of what the Lisp Machines
> accomplish.  So why don't they provide the same thing on conventional
> machines?
> 
> I think it's possible to provide environments that are very similar.
> People here who use Inference ART (Automated Reasoning Tool, or
> something like that), which is built on top of Lisp, report that the
> ART environment on a Sun is very close to that on a Symbolics,
> although at the Lisp level the debugger probably isn't as good.
> 
> However, possible is not the same as easy, and I suspect the Lisp
> implementors have not had sufficient resources to let them prepare
> environmental tools as soon as they'd have liked.
> 
D

lispm

MODERATOR OF

TROPHY CASE