Paolo Amoroso's Journal

Interlisp

I fixed a bug in the initial code of WebCard, my RetroChallenge 2024 project.

An infinite loop in the constructor of the Web card type caused a stack overflow that aborted Medley. The Web constructor was supposed to call the constructor of the parent card type Text. But I misunderstood the NoteCards API and used NCP.CardTypeFn which ended up calling the Web constructor itself, hence the infinite loop.

The fix was easy: call the supertype's constructor with NCP.ApplySuperTypeFn. Troubleshooting the issue was a great learning experience.

With the bug out of the way I fleshed out a bit more of the Web card constructor. I wrote code to query the user for a URL and store it in the property list of the card. This gives persistence for free as NoteCards automatically stores properties to and retrieves them from notefiles.

There's still some card initialization to do in the case the constructor is passed the option to not display the card, but I'll leave it for later.

In my initial plan the constructor would query the user also for an optional card title but I dropped the idea. NoteCards already allows adding and editing card titles, so forcing this from the constructor seems redundant and possibly confusing. Like NoteCards, by default WebCard names new cards Untitled.

Reporting my progress and plans to the Medley Interlisp team sparked an interesting conversation on rapid prototyping in Interlisp and the Lisp development style. For example, I learned the Interlisp advising functionality was designed as a prototyping tool.

I'm not yet sure what to work next, whether to handle card editing or go straight for the website visiting functionality. The latter is the only missing piece of an early prototype.

#WebCard #Interlisp #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

The initial Interlisp code of WebCard, my RetroChallenge 2024 project, defines the new type “Web” of NoteCards card. It's the first step for extending NoteCards to visit websites.

The main code is in the function WCD.CreateWebCardType, a thin wrapper around the NoteCards API function NCP.CreateCardType. The former passes to the latter the name of the new type Web, the name of the type Text it inherits from, an alist of functions that implement the overridden card operations, and an alist of customization parameters.

So far the only operation the Web type overrides is card creation via the constructor WCD.MakeWebCard. The function crashes Medley and ends the session but I left it there as I wanted to have something in place.

Although the initial code is little more than a stub, it's an important foundation the rest of WebCard will flesh out or build upon.

Next, I need to figure out why WCD.MakeWebCard crashes. Aside from removing a roadblock, the troubleshooting will provide insight into how card creation works.

The code is available at the project repo. WebCard function names and symbols start with the WCD. prefix as a form of limited namespace isolation as Interlisp has nod direct support for packages.

#WebCard #Interlisp #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

Now that I entered the RetroChallenge 2024 the next step is to flesh out the scope and details of my WebCard project, a NoteCards extension for visiting websites. What will WebCard do? How will it work?

Specification

In NoteCards the area of a card or filebox that makes up a link icon, when clicked, displays a destination card or filebox. Links typically look like outlined rectangles that contain a bitmap and the title of the destination.

The destination of a WebCard link is a page on the World-Wide Web designated by a URL.

Clicking on a WebCard link icon, which has a custom bitmap, will launch the web browser of the host operating system, if not already running, and direct the browser to visit the URL associated with the WebCard link. WebCard will also display a stand in NoteCards card that shows the URL and title of the web page, advising to view the page itself in the browser. No text, links, or media can be inserted in the stand in card.

Clicking on the same WebCard link more than once will notify that the associated web page may already be displayed in the browser, offering to direct the browser to visit the page again.

Other than that WebCard and NoteCards will have no control over the browser and its tabs and windows, which the user may close or change at any time. Since WebCard is not a WebView it won't render web pages or HTML either.

To add a web link to a hypertext the user will create a card of type Web. WebCard will ask for the destination URL and an optional title and create a stand in card that displays the information. The user will then insert NoteCards links to Web cards with the usual link creation commands and specify an appropriate stand in card as the destination.

WebCard will come with basic documentation and sample notefiles that demonstrate web links.

Design

To implement this functionality WebCard needs a way of opening web pages in a browser and adding clickable web links to a hypertext.

Opening web pages

Opening web pages from Lisp is easy.

As part of the modernization effort the Medley Interlisp team implemented UNIXUTILS, a library of utilities for running Unix programs and controlling processes. The UNIXUTILS function ShellBrowse does exactly what I want: it executes the xdg-open command of the host operating system and passes it a URL to open in the system browser.

As a consequence of this decision the host operating system must support the relevant XDG specification.

As for inserting clickable web links, the design of NoteCards funnels to a natural solution.

In NoteCards, the destination of a link must be a card or filebox. Therefore, for a link to lead to a web site, the link can have as its destination a special card that stands for the associated web URL. Traversing that link triggers the activation of the web browser.

The NoteCards API supports defining new types of cards with custom behavior implemented as a set of standard operations. Since card types are arranged in an inheritance hierarchy, defining a new type often involves overriding just a few operations and letting the system invoke the default behavior of the parent types for the others.

WebCard will define the new card type Web that inherits from the Text card. I expect to override a handful of operations, mostly for card creation and editing.

WebCard needs to activate the browser when a Web card is opened or displayed as a result of traversing a link. But since the API doesn't support overriding or hooking into these operations I'll have to come up with something different, such as advising the default behavior. The advice will direct the browser to visit the URL and pass control to the default behavior to open or display the stand in Web card in NoteCards.

The NoteCards API does allow to override the operation of traversing links to cards. I may augment such a behavior to also control the browser for Web card destinations, which may be easier and cleaner than adivising other operations.

As for editing, WebCard will allow changing only the URL and title of a card but not the content. Aside from that, I hope to get away with skipping the default editing behavior without having to interact with TEdit. It's an indirect way of making the Web card content read only.

Discussion

Along with the supporting functions and data, implementing this functionality should be achievable in one month or less.

WebCard will have little control over a web browser. In addition, web pages will be displayed only in a browser outside of NoteCards. Despite the limitations, I expect WebCard to provide genuinely useful functionality and allow integrating hypertexts with external content.

The design of WebCard is similar to traditional NoteCards extensions. When the system was in active use in the 1980s, some extensions invoked external functionality such as controlling laserdiscs or playing media, or connecting to dial-up databases to perform queries and populate cards with the results.

#WebCard #Interlisp #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

Team Lisp is ready to play: I'm entering the RetroChallenge 2024 (RC2024) with a NoteCards project targeting Medley Interlisp.

The RC2024 announcement explains the point of the challenge is to do something new, learn, and have fun with retro systems:

In a nutshell, the RetroChallenge is a loosely disorganised gathering of RetroComputing enthusiasts who collectively do stuff with old computers for a month.

The goal of my RC2024 project, WebCard, is to extend NoteCards to visit sites on the World-Wide Web. The project logo borrows the NoteCards card box icon and its nice retro vibes:

CardBox icon of the NoteCards hypermedia system of the Medley Interlisp environment.

NoteCards is a pioneering hypermedia system developed at Xerox PARC in the 1980s as a Medley Interlisp application. Since it's a pre-web system, NoteCards runs locally and never interacted directly with the web. So I'll develop an extension to open sites using the web browser of the host operating system Medley Interlisp runs under.

However, WebCard is not meant as a WebView or anything like that. Although it will just open websites by calling a modern browser, the feature will expand the hypertext capabilities of NoteCards in interesting ways.

My main motivation for the project is to continue the learning and fun I'm having experimenting with NoteCards.

This is also an opportunity to bridge the past and present of hypertext. And, since I'm in the Medley Interlisp project team who comprises some of the original developers, including NoteCards co-creator Frank Halasz, I'll be able to discuss and learn the system from its own implementors. Which, again, is a way of bridging the past and present of computing.

I will host the code on the WebCard repository, publish reports on the project blog (feed), and post short but more frequent updates on my @amoroso@fosstodon.org Mastodon account under the RC2024 hashtag.

This idea is a crazy frankentext but it can work. I look forward to clicking the start link.

#WebCard #Interlisp #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

I'm examining in depth NoteCards, the hypermedia environment of Medley Interlisp well described in the 1987 paper NoteCards in a Nutshell.

To experiment with the NoteCards API I set out to explore the space of possible answers to the question: what if Lisp programs were represented as NoteCards hypertexts? Leveraging NoteCards to play with the idea seemed like a natural extension to Sysrama, my Interlisp documentation tool for presenting information on the objects of Lisp programs.

The rich environment of NoteCards allowed me to quickly put together what I wanted as the system provides an extensive, well designed, well documented, and easy to use API.

Generating hypertexts with NoteCards and Sysrama

As a start I wrote a Sysrama function that produces a hypertext representation of a program by querying the File Manager. The function, appropriately named CODECARDS, creates a notefile and populates it with cards and fileboxes.

In NoteCards, a “card” is the unit of information the nodes of a hypertext network store and present. A card can hold text, media, and more. A “filebox” is a container of cards and fileboxes. The fileboxes and cards of a hypertext are stored on disk in a “notefile”.

CODECARDS, which is passed the file name of a program as the only argument, sets up a filebox for every non empty File Manager type of the program. It further creates one card for every Lisp object of the type, fills the card with information on the object, and files the card under the type's filebox. The fileboxes are filed under the Table of Contents filebox. A side effect of filing the cards and fileboxes is the creation of a series of system links to construct and navigate the hierarchical structure.

The generated cards and fileboxes can be manipulated with NoteCards' suite of hypertext editing and navigation tools such as the graph browser.

After evaluating (CODECARDS 'SYSRAMA) to process Sysrama's own code, opening some fileboxes and cards, and arranging them on the desktop the Medley screen may look like this:

Some fileboxes and cards of a NoteCards hypertext on Medley Interlisp.

The Table of Context filebox in the top row of windows, between the NoteCards icon and the Medley logo, contains links to the fileboxes of the File Manager types. The links are the rectangular outlines with an icon at the left and a textual description in the rest of the outline.

Clicking on the VARS (variables), FNS (functions), and EXPRESSIONS (expressions) links of the Table of Contents opens the corresponding fileboxes of the middle row of windows. Section FILE BOXES has no entries because the fileboxes contain only cards.

The leftmost in the bottom row of three windows is the filebox of the type FNS (functions). Every one of its links leads to the card of the Lisp function indicated by the link name. The two rightmost windows of the bottom row are the cards of functions CODECARDS and DESCRIBEFNS with the shown signatures ((CODECARDS FILE) and (DESCRIBEFNS FNS TYPE)) and type (EXPR LAMBDA-spread).

The window at the bottom left of the screen is a browser, a NoteCards editing and navigation tool for visualizing and manipulating a hypertext as a graph. The trees in the browser represent the hierarchical structures of fileboxes and cards CODECARDS produces.

Note the VARS, FNS, and FILEVARS fileboxes at the roots of the trees in the browser. The leaves are cards.

Sysrama and the File Manager

The Medley File Manager should not be confused with the similarly named tool of desktop operating systems for navigating and manipulating files and folders. As I wrote in a post on using Common Lisp in the residential environment:

The File Manager, also known as “File Package” (not to be confused with Common Lisp packages), is a facility that coordinates the development tools and code management tasks. It notices the changes to Lisp objects edited with SEdit or manipulated in memory, tracks what changed functions and objects need to be saved to symbolic files, and carries out the actions for building programs such as compiling or listing them. The File Manager has some of the functionality of Unix Make.

The File Manager stores Lisp sources in “symbolic files”, which are code and metadata databases rather than ordinary source files.

Sysrama and CODECARDS query the File Manager metadata associated with a program to present information about its Lisp objects, such as functions and variables, and build a notefile.

Next steps

So far CODECARDS doesn't do much as it's an early proof of concept to explore the idea of representing programs as hypertexts. The evolution of the feature will point to where the idea can lead.

The hypertext functionality of Sysrama relies only on system links and doesn't define user links, i.e. user defined connections that establish typed relationships between the end points. Also, I'm thinking about whether and how to update the notefile with the changes the associated program undergoes during development.

The next tasks I'll likely work on are fleshing out the information in the Lisp object cards and defining some user links.

#Interlisp #sysrama #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

Although online access to Medley Interlisp is convenient and prebuilt binaries are available for all major operating system, it's also possible to compile it from source.

I first built Medley from source when I wanted to run it on my Raspberry Pi 400 and no ARM64 binaries were available. I later built Medley on Linux to try other options such as SDL2 support instead of X11. Since the build process is simple and fast, even on low-end devices such as the Pi 400, now I often do it on Linux.

There are some compilation instructions and notes for Maiko and Medley (see also the scripts README) but not a full build guide, so I fleshed out the details with the help of the project team.

I initially didn't write down the process as I relied on memory, which sometimes made me take wrong turns and waste time. This post finally puts together all the required steps and information for my own reference, and I hope it will be useful to you too.

Building Medley involves downloading the sources, configuring the environment, compiling the Maiko Virtual Machine, and generating the Medley system image.

What to build

Medley provides a number of compilation options, such as SDL2 support as an alternative to X11, with configurations that range from a minimal system to a complete build that includes all the Lisp applications like NoteCards.

These instructions cover building the complete system, which Medley veterans frequently refer to as the “apps sysout” as a sysout is a Lisp image.

Assumptions

The process I describe assumes you'll build the system on Linux using Clang. If you prefer Gcc the Maiko README file explains what to do. In addition I assume you're familiar with the Unix C toolchain and the shell.

Although the instructions may work on similar platforms, if you're not on Linux you'll need to adapt them to your setup.

The setup

The tools to compile Medley are the same as for C development on Linux, with a few additional dependencies. Make sure the following packages are installed on your system:

  • Clang: clang
  • Make: make
  • X11 development libraries: libx11-dev
  • SDL2 development libraries (optional): libsdl2-dev

libsdl2-dev is needed only if you want SDL2 instead of X11.

I store the Medley sources under ~/interlisp and the build instructions assume this location. Change to the ~/interlisp directory and download the required files.

The Medley Interlisp project automatically publishes weekly binary builds whereas the project repositories hold the source tree. Since there is really no stable source release per se, these instructions assume you use git to download the sources of Maiko, Medley, and NoteCards:

$ cd ~/interlisp
$ git clone https://github.com/Interlisp/maiko.git
$ git clone https://github.com/Interlisp/medley.git
$ git clone https://github.com/Interlisp/notecards.git

The repos are pretty large, so to save space and bandwidth you may want to run git with the --depth 1 option.

After the download the source directory will contain the following subdirectories:

.
├── maiko
├── medley
└── notecards

The build steps

The Medley system consists of two layers, Maiko and the Medley environment.

The bottom layer is the Maiko Virtual Machine, written in C, which implements the evolution of the microcode of the Xerox workstations that ran Interlisp-D in the 1980s. The rest of the system in the top layer, the actual Medley environment the user interacts with, is written in Lisp.

The build process reflects this layered organization. You first compile Maiko with the C toolchain, then run the scripts that drive the Lisp environment to compile the Lisp sources and produce a loadable image, i.e. a sysout.

Building Maiko

Start by changing to the maiko/bin directory of your source tree. To build Maiko for X11 clean up any leftovers from prior invocations and run the build:

$ cd ~/interlisp/maiko/bin
$ ./makeright x cleanup
$ ./makeright x

Next, build the ldeinit Maiko tool required for producing the apps sysout:

$ ./makeright init

These steps create the executable files lde, ldex, and ldeinit under ../ostype.cputype, e.g. ../linux.x86_64 on typical Linux systems. Move the lde* programs to or symlink them from somewhere in your executable path.

If you want the SDL2 version instead of X11 substitute sdl for x in the above build commands:

$ ./makeright sdl cleanup
$ ./makeright sdl
$ ./makeright init

On my Linux system these compilation steps collectively take a dozen seconds of runtime.

Doing the loadup

The final step is to make the apps loadup.

A “load up”, or just “loadup”, is a platform independent Lisp image generated by the Lisp side of the build process. Historically, building the Medley sysout was called “doing a loadup”. Along with an image, doing the loadup produces a set of compiled Lisp and supporting files.

To do the loadup change to the Medley directory ~/interlisp/medley, remove the loadups subdirectory to clean up any leftovers from prior builds, and launch the driver script loadup-all.sh in the scripts subdirectory:

$ cd ~/interlisp/medley
$ ./scripts/loadup-all.sh -apps

The Medley graphical environment will open several times and print log messages on the files it is compiling or other status information.

During this step it is amazing to watch the Medley window and log messages zip by in seconds in a process that took many hours back in the day. On my Linux system this step completes in about 3 minutes and 10 seconds.

Testing the build

Your environment is already set up for building Medley and no additional steps are required for installing and running it.

When the build ends, test Medley by launching the medley command. For example, execute medley with the -a option to load the applications, -e to start an Interlisp Exec, and -n to remove the screen scroll bars that are not much useful:

$ cd ~/interlisp/medley
$ ./medley -a -e -n &

Execute ./medley --help to get a brief help message with a list of the command line options, and ./medley -z to read the manual page.

#Interlisp #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

I implemented the last features originally planned for Insphex, my hex dump tool in Common Lisp for Medley Interlisp.

The first new feature is an Exec command for invoking the program. The command HD works the same way as the function INSPHEX:HEXDUMP and accepts the same arguments, a file name and an optional boolean flag to indicate whether the output should go to a separate window:

← HD FILENAME [NEWIN-P]

The other feature is the addition to the File Browser menu of the Hexdump command, which shows the hex dump of the selected files in as many separate windows:

Hexdump File Browser command of the Insphex hex dump tool on Medley Interlisp.

For other commands that produce output in windows the File Browser lets the user view one window at a time, with menu options for skipping through the windows. Insphex doesn't do anything so elaborate though.

Implementing the features was easy as the relevant Interlisp APIs are well documented and I have experience with adding an Exec command to Stringscope.

The Medley Lisp library modules manual covers the File Browser API from page 115 of the PDF, with the explanation of how to add commands on page 118. It's as simple as registering a callback function the command invokes, INSPHEX::FB-HEXDUMP for Insphex.

An issue I bumped into is that instead of 4 arguments as the manual says, the callback actually requires 5. The last, undocumented argument was likely introduced since the publication of the manual.

#insphex #CommonLisp #Interlisp #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

I added a GUI to Insphex, the hex dump tool I'm writing in Common Lisp on the Medley Interlisp environment.

The initial version printed the hex dump only to the standard output, now optionally to a separate TEdit window with a command menu. The menu has items for displaying the next page of output, redisplaying from the beginning of the file, and exiting the program.

Window and command menu of the Insphex hex dump tool for Medley Interlisp.

Most window, menu, and other Medley GUI facilities, like the TEdit rich text editor, provide Interlisp APIs in the IL package that Common Lisp programs such as Insphex can access. However, since the APIs usually rely on Interlisp records, from Common Lisp it's often necessary to write quite a few package qualifiers like this example to create a menu record:

(IL:CREATE IL:MENU
           IL:ITEMS IL:← '(ITEM1 ITEM2 ITEM3)
           IL:MENUFONT IL:← '(IL:MODERN 12)
           IL:TITLE IL:← "Menu"
           IL:CENTERFLG IL:← T)

The XCL:DEFINE-RECORD macro helps reduce package qualifiers by wrapping Interlisp records in equivalent Common Lisp structures with ordinary structure accessors, setters, predicates, and constructors. The structures can be in any package, not just IL like Interlisp symbols. XCL:DEFINE-RECORD is described on page 7-3 (page 143 of the PDF) of the Medley 1.0 release notes.

This way Common Lisp blends well with Interlisp and reduces verbosity. For example, this is the Insphex Common Lisp function that creates the output window:

(DEFUN CREATE-HEX-WINDOW (FILE)
   "Create and return a window to display the hex dump of FILE."
   (LET* ((IN (OPEN FILE :DIRECTION :INPUT :ELEMENT-TYPE '(UNSIGNED-BYTE 8)))
          (COMMANDS (IL:MENUWINDOW (MAKE-MENU :ITEMS '(("Next" :NEXT "Show the next page.")
                                                       ("Reread" :REREAD "Reread the input file.")
                                                       ("Exit" :EXIT "Quit the program."))
                                          :MENUFONT
                                          '(IL:MODERN 12)
                                          :TITLE "Commands" :CENTERFLG T :WHENSELECTEDFN 
                                          #'HANDLE-MENU)))
          (OUT (IL:OPENTEXTSTREAM))
          (TEDIT-PROC (IL:TEDIT OUT))
          (WINDOW (IL:WFROMDS OUT)))
     (IL:ATTACHWINDOW COMMANDS WINDOW 'IL:TOP 'IL:LEFT)
     (IL:WINDOWPROP WINDOW 'INSTREAM IN)
     (IL:WINDOWPROP WINDOW 'OUTSTREAM OUT)
     (IL:WINDOWPROP WINDOW 'BLOCK-OFFSET 0)
     (IL:WINDOWPROP WINDOW 'IL:TITLE (FORMAT NIL "Insphex ~A" FILE))
     (NEXT-HEX-PAGE WINDOW)
     WINDOW))

The INSPHEX::MAKE-MENU constructor creates a Common Lisp INSPHEX::MENU structure that wraps the Interlisp IL:MENU record.

Most of the Insphex GUI functionality is in place but I need to work on a couple of tweaks.

First, the Insphex window should be read-only whereas now the user can type into the editor buffer. Next, I need to clean up all the allocated resources when the user quits the program via various interaction flows, such as closing the window instead of clicking the Exit menu item.

#insphex #CommonLisp #Interlisp #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

I'm developing the new program Insphex (inspect hex), a hex dump tool that is created with and runs on the Medley Interlisp environment.

Similarly to the Linux command hexdump, it shows the contents of files as hexadecimal values and the corresponding ASCII characters. An early version of the program prints the hex dump to the standard output like this.

Output of the Insphex hex dump tool for Medley Interlisp.

I plan to enhance Insphex to optionally display the dump in a separate window one page at a time. An attached menu will have options for showing the next page and exiting. I'll also provide an Exec command for running the program.

The code is in Common Lisp but will include some Interlisp to access the required system functionality.

Although Insphex is useful in itself, I have three main goals for it. First, I want a real project to practice the process for writing Common Lisp with the residential environment of Medley. This is the native way of coding on Medley and takes full advantage of its development environment and features such as the File Manager and the SEdit editor.

Most Medley tools and facilities are written in Interlisp or expose Interlisp APIs through which the functionality can be invoked. So another goal is to interface with Interlisp from Common Lisp to access the functionality I need like windows and menus.

My third goal is to experiment with displaying textual output in TEdit, the Medley word processor where the hex dump will optionally go.

Although the Interlisp API of TEdit supports advanced editing and formatting, Insphex does only basic text output. The primary feature I want is TEdit's ability to automatically handle repainting the window after it's resized or a hidden portion is exposed. This is handy as by default Interlisp windows mostly don't handle the repaint.

Now that the basic functionality of Insphex is in place I will implement displaying the hex dump in a TEdit window.

#insphex #CommonLisp #Interlisp #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

When the Medley Interlisp Project began reviving the system around 2020, its Common Lisp implementation was in the state it had when commercial development petered off in the 1990s, mostly prior to the ANSI standard.

Back then Medley Common Lisp mostly supported CLtL1 plus CLOS and the condition system. Some patches submitted several years later to bring the language closer to CLtL2 needed review and integration.

Aside from these general areas there was no detailed information on what Medley missed or differed from ANSI Common Lisp.

In late 2021 Larry Masinter proposed to evaluate the ANSI compatibility of Medley Common Lisp by running the code of popular Common Lisp books and documenting any divergences. In March of 2024 I set to work to test the code of the book Practical Common Lisp by Peter Seibel.

I went over the book chapter by chapter and completed a first pass, documenting the effort in a GitHub issue and a series of discussion posts. In addition I updated a running list of divergences from ANSI Common Lisp.

Methodology

Part of the code of the book is contained in the examples in the text and the rest in the downloadable source files, which constitute some more substantial projects.

To test the code on Medley I evaluated the definitions and expressions at a Xerox Common Lisp Exec, noting any errors or differences from the expected outcomes. When relevant source files were available I loaded them prior to evaluating the test expressions so that any required definitions and dependencies were present. ASDF hasn't been ported to Medley, so I loaded the files manually.

Adapting the code

Before running the code I had to apply a number of changes. I filled in any missing function and class definitions the book leaves out as incidental to the exposition. This also involved adding appropriate function calls and object instantiations to exercise the definitions or produce the expected output.

The source files of the book needed adaptation too due to the way Medley handles pure Common Lisp files.

Skipped code

The text and source files contain also code I couldn't run because some features are known to be missing from Medley, or key dependencies can't be fulfilled. For example, a few chapters rely on the AllegroServe HTTP server which doesn't run on Medley. Although Medley does have a XNS network stack, providing the TCP/IP network functions AllegroServe assumes would be a major project.

Some chapters depend on code in earlier chapters that uses features not available in Medley Common Lisp, so I had to skip those too.

Findings

Having completed the first pass over Practical Common Lisp, my initial impression is Medley's implementation of Common Lisp is capable and extensive. It can run with minor or no changes code that uses most basic and intermediate Common Lisp features.

The majority of the code I tried ran as expected. However, this work did reveal significant gaps and divergences from ANSI.

To account for the residential environment and other peculiarities of Medley, packages need to be defined in a specific way. For example, some common defpackage keyword arguments differ from ANSI. Also, uppercase strings seem to work better than keywords as package designators.

As for the gaps the loop iteration macro, symbol-macrolet, the #p reader macro, and other features turned out to be missing or not work.

While the incompatibilities with ANSI Common Lisp are relativaly easy to address or work around, what new users may find more difficult is understanding and using the residential environment of Medley.

Bringing Medley closer to ANSI Common Lisp

To plug the gaps this project uncovered Larry ported or implemented some of the missing features and fixed a few issues.

He ported a loop implementation which he's enhancing to add missing functionality like iterating over hash tables. Iterating over packages, which loop lacks at this time, is trickier. More work went into adding #p and an experimental symbol-macrolet.

Reviewing and merging the CLtL2 patches is still an open issue, a major project that involves substantial effort.

Future work and conclusion

When the new features are ready I'll do a second pass to check if more of the skipped code runs. Another outcome of the work may be the beginning of a test suite for Medley Common Lisp.

Regardless of the limitations, what the project highlighted is Medley is ready as a development environment for writing new Common Lisp code, or porting libraries and applications of small to medium complexity.

#CommonLisp #Interlisp #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org