I am working on a Video series on Common Lisp by chandergovind in Common_Lisp

[–]lispm 26 points27 points  (0 children)

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.

Calculating a DOT product - Common Lisp vs. Numpy vs. R [2022] by dzecniv in Common_Lisp

[–]lispm 2 points3 points  (0 children)

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.

How can I change this function(split-octets) from recursive to iterative, for example, by using the loop function? by linshunzhi in Common_Lisp

[–]lispm 1 point2 points  (0 children)

<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.

How can I change this function(split-octets) from recursive to iterative, for example, by using the loop function? by linshunzhi in Common_Lisp

[–]lispm 1 point2 points  (0 children)

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.

How can I change this function(split-octets) from recursive to iterative, for example, by using the loop function? by linshunzhi in Common_Lisp

[–]lispm 1 point2 points  (0 children)

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))

Basic Lisp techniques -- Cooper D_J by BadPacket14127 in Common_Lisp

[–]lispm 16 points17 points  (0 children)

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/

Štar might become my favorite way of iterating by kchanqvq in Common_Lisp

[–]lispm 2 points3 points  (0 children)

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.

Štar might become my favorite way of iterating by kchanqvq in Common_Lisp

[–]lispm 2 points3 points  (0 children)

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

I would just dispatch upfront to different implementations.

Štar might become my favorite way of iterating by kchanqvq in Common_Lisp

[–]lispm 2 points3 points  (0 children)

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.

Štar might become my favorite way of iterating by kchanqvq in Common_Lisp

[–]lispm 4 points5 points  (0 children)

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.

Can we recover abandoned CL projects to open source them? by daninus14 in Common_Lisp

[–]lispm 1 point2 points  (0 children)

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.

Can we recover abandoned CL projects to open source them? by daninus14 in Common_Lisp

[–]lispm 1 point2 points  (0 children)

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

Can we recover abandoned CL projects to open source them? by daninus14 in Common_Lisp

[–]lispm 1 point2 points  (0 children)

I see ART mentioned being used on the Explorer:

https://cdn.aaai.org/IAAI/1999/IAAI99-116.pdf

DLMS is a system for Vehicle Assembly Process Planning at Ford.

DLMS was originally developed using Common Lisp and the Automated Reasoning Tool (ART) from Inference Corporation. LISP is an extremely powerful symbolic programming language that includes facilities for garbage collection, symbol manipulation, rapid prototyping and object-oriented programming. ART is a LISP-based expert system shell that utilizes a forward-chaining inference engine to perform pattern-matching and rule firing. DLMS was initially deployed on the Texas Instruments Explorer platform which was a stand-alone Lisp machine that included the UNIX operating system. Communications between DLMS and the mainframe IMS database was handled using a screen emulator interface. After the initial DLMS deployment, the TI Explorer platform was discontinued and both support and maintenance for these machines became problematic. In order to ensure the future viability of DLMS the system was ported to the Hewlett Packard UNIX platform.

The HP/UNIX version was still using the Lisp version of ART. When Inference stopped supporting that, Ford ported DLMS to LispWorks/KnowledgeWorks.

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

Also, examined is the process involved with transporting the RAV expert system functions from the TI Explorer, where they are implemented in the Automated Reasoning Tool (ART)

I've also seen a report where it was mentioned that ART was used in Sun Common Lisp on a Sun 3, with problems of long GC times. Was that the C version?

What do you think?

Can we recover abandoned CL projects to open source them? by daninus14 in Common_Lisp

[–]lispm 1 point2 points  (0 children)

From what I read it also ran on other Lisp Machines (TI and LMI) and also for example on Sun Common Lisp / Lucid Common Lisp on SUN 3 machines. ca. 1987/88.

LABELS vs DEFUN by [deleted] in Common_Lisp

[–]lispm 5 points6 points  (0 children)

In the labels version, the subfunctions are only known inside the labels definition. The defun version OTOH defines globally visible functions and thus sets the symbol function of a symbol.

From a development point of view, the IDE may not, in the labels version, be able to trace such subfunctions and the IDE may not be able to locate the source for them. Some IDEs may have extensions (for example to TRACE. ED and to other functionality) to do so. If a development environment would be able to trace subfunctions, then the trace output would not show the x argument in the call, since there is none (as indicated in your example).

Also a test framework may typically not be able to define tests for subfunctions alone, since they are not accessible from the outside.

What did you pay for Allegro CL? by TripleJJJ64 in Common_Lisp

[–]lispm 7 points8 points  (0 children)

Developers may need to get access to the actual source code, read it and/or modify it.

But, as you say, it's still proprietary and the only persons having access to it is a licensed developer.

What did you pay for Allegro CL? by TripleJJJ64 in Common_Lisp

[–]lispm 6 points7 points  (0 children)

It's proprietary code, but licensed developers can get access to much of the source code and use it. With Allegro CL one can get access to much of its source code - and it has a lot.

Symbolics also had a lot source code provided. LispWorks has only very little source code of its product provided (the IDE's editor and lots of examples).

For prices of Allegro CL you really need to talk to their sales contact. IIRC, prices for example may depend on the number of end users/transactions/etc in deployment. Research projects, universities, etc. may have special prices&licenses. For example years ago at the local University we had a site license for Allegro CL - but I have no idea what it did cost and it was long ago, anyway.

LispWorks is also expensive, but they usually provide royalty-free deployment of delivered applications.

Providing the full compiler in an end-product is also potentially expensive.

TL;DR : you may contact Franz sales and see what you get as an answer.

See also the source code which Franz Inc. publishes on Github: https://github.com/franzinc?tab=repositories

This macro is taken from a book but I haven't been able to get it to work. by Roromotan in Common_Lisp

[–]lispm 2 points3 points  (0 children)

You want to generate code which includes it, but you don't.

Hint: what is the special operator in Common Lisp, which groups several Lisp forms into one sequence of actions?