Evaluating Medley compatibility with Common Lisp: An Interactive Approach

[eblanton]

I have started working through Common Lisp: An Interactive Approach. Per the discussion on Issue 609, I am going to report results here, commenting only on incompatibilities and difficulties over there.

I am creating and managing files and packages, where the book requests that I do so, according to Paolo's guidelines here. I have found that the XCL:DEFINE-FILE-ENVIRONMENT call must be made in an Interlisp exec window (it's possible that running it from the Interlisp package in an XCL exec might work, I haven't tried it). My workflow is to invoke XCL:DEFINE-FILE-ENVIRONMENT, then (MAKEFILES) and associate the file environment with a filename, then DC the filename and add the package definition, (MAKEFILES) again, and LOAD the file. This prevents me from having to type the package definition more times than absolutely necessary. The interaction between the :PACKAGE argument provided to XCL:DEFINE-FILE-ENVIRONMENT and the DEFPACKAGE form in (P) is not fully clear to me, but I have been treating the former as more or less immutable after creation and the latter as a Common Lisp defpackage and it has been working for me.

I will comment on the first few chapters here, and use replies for future chapters as I get to them.

• Chapter 1: no issues. The interesting answers to the exercises are:
  • (il:logout) or (il:logout t) to log off
  • C-b for the interrupt key to open a debugger
  • use the middle mouse button and select up arrow to exit a debugger level
  • use C-d to continue from a deep nesting in the debugger.
• Chapter 2: no issues
  • As Paolo noted here, semicolon comments on a line cause the interactive repl to wait for a second form before continuing.
  • As far as I can tell, the s, f, d, and e floating point formats all behave the same, but I cannot tell whether this is an artifact of the printer or whether they are actually equivalent in precision.
  • Backspace and C-u work for line editing, Unix-style
• Chapter 3: no issues
• Chapter 4: no issues
• Chapter 5: no issues
  • XCL prints #\Newline, not #\NEWLINE, for 5.16, but as 5.15 points out, this is immaterial
• Chapter 6: no "real" issues; some representational differences
  • At the XCL prompt, the package is of course XCL-USER, not USER; the LISP exec package is USER
  • The print form of 'f\rank in XCL is F\rANK, not |FrANK| as printed in the book
  • Here we see that the floating point question above resolves to the fact that all numbers input (with s, e, d, l, or f exponents) are SINGLE-FLOAT
  • Exercise 6.8, (eql "string" "string") is false, as suggested may be the case
• Chapter 7
  • Here the difference between an XCL exec and a COMMON-LISP exec starts to become obvious, because of package name differences. Otherwise, things are fine.

[eblanton]

• Chapter 8: one possible issue
  • The behavior of type-of for nil is surprising in Medley. This is true for both XCL and COMMON-LISP executives.
• Chapter 9: no "real" issues; one confusion
  • Exercise 10.3 does not drop into the debugger, which CL:aIA seems to expect. I don't think this is a bug. I suspect that this is a configurable behavior.
• Chapter 10: no issues
• Chapter 11: no issues

[pamoroso]

Yes, whether to drop into the debugger is configurable. In addition, after evaluating an expression you expect to break but doesn't, just execute RETRY from the Exec to reevaluate it and invoke the debugger.

[pamoroso]

As for configuring, evaluate (SETQ IL:HELPTIME -1) to make all error conditions break into the debugger on error.

[eblanton]

OK, Chapter 12 is where it gets interesting, so it's going to get its own post.

Chapter 12 is about creating and editing Lisp source files, and it assumes a file-and-editor based Lisp interaction; it does mention the TI Explorer Lisp Machine, but from the description I suspect it handles files in a similar way to SLIME in Emacs. It describes a two-buffer editing approach in Emacs, etc., which is fine, but the description doesn't map super well to the Medley interaction of SEdit, REPL, (FILES?), (MAKEFILE), etc. Someone using this book would need an alternate Chapter 12 at this point for those reasons, but that is all expected, so I'll leave it aside for now.

Once the user understands Medley file management, most of the rest of the material here is fine, except that:

• in-package works at the REPL in Medley, but it doesn't go in the source files (source seems to be fully qualified for every defun/etc.)
• There is no (defpackage) in LISP, only in XCL; see Defpackage is in package XEROX-COMMON-LISP instead of LISP #1684
• :shadowing-import-from and :import-from are given in the (defpackage) example on p. 70 just before the exercises, but do not seem to be supported by XCL::DEFPACKAGE.

This chapter begins the project exercises, which build to two significant bodies of code by the end of the book. These exercises work fine.

[pamoroso]

in-package should work in pure Common Lisp files, I used it for testing the code of Seibel's book. But, as you noted, symbolic files under the File Manager are handled differently.

I seem to have read, but can't find a reference right now, that defpackage was in XCL as a result of the work in progress on Common Lisp compatibility back when development of Medley was winding down. An eventual move or addition to LISP was planned.

The lack of :import-from and :shadowing-import-from is a known issue but they can be replaced by :import and :shadowing-import. See "Section 11. Packages" of this post of #5.

[eblanton]

Did you edit your pure common lisp files outside of Medley entirely and just (load) them? If so, did you have to do anything with readtables/etc. (or was reading them from a LISP or XCL exec enough)?

As far as defpackage not being in LISP, the issue isn't that it's not defined in LISP, but that it's not immediately accessible from LISP. Importing it from XCL would solve the issue from my perspective, although I'm not sure if that introduces other bugs.

[pamoroso]

I edited pure Common Lisp files both outside and inside Medley with TEdit and loaded them as explained here.

[eblanton]

• Chapter 13: no issues

• Chapter 14: no issues

• Chapter 15: stability issue

  • Exercise 15.4 asks you to enter this program:

    (defun sum (n1 n2)
      (assert (and (integerp n1) (>= n1 0)) (n1)
       "N1 must be a nonnegative integer, instead it's ~S."
        n1)
      (assert (integerp n2) (n2)
        "N2 must be an integer, instead it's ~S."
        n2)
      (if (zerop n1) n2
        (sum (1- n1) (1+ n2)))

    It then asks the reader to "Try with some large integers as its first argument. Can you find an integer so large that an error occurs?" That's fine, and an error does occur, but the error is that lde crashes and the Medley window becomes unresponsive. It isn't obvious how to fix this problem from the lde prompt, or if it can even be fixed. This problem of course goes away if the user runs (compile 'sum) first, although running (sum) on large values still takes a very long time.
  • Exercise 15.7 asks the user to interrupt a long-running computation; C-b does this. It turns out that "OK" is the response that actually continues and completes the computation.
  • Exercise 15.8 is trivial in Medley!
  • Exercise 15.10 crashes lde again
  • Exercises 15.12, 15.13, and 15.14 run a real risk of crashing lde during testing for the same reasons

[eblanton]

Chapter 16: stability issues

Chapter 16 includes some examples that shadow symbols in LISP:. If the user does not (shadow) them a priori, in at least some cases completing the form can crash maiko with a stack overflow. For example, this form from Page 90 crashes lde:

(defun length (l)
(if (null l) 0 (1+ (length (rest l)))))

Again, I'm not sure if this is a bug to be tackled, or not. For now, I will continue to flag these speed bumps for using CL:aIP, but I am not filing bugs.

All of the exercises and examples in this chapter work fine as long as the user shadows appropriately before defining new functions.

[eblanton]

Chapter 17:

• Chapter 17 is pending some way to get around Shadowed symbols in Xerox Common Lisp do not behave as expected #1755.
• A very interesting observation occurs in 17.20; this exercise involves shadowing LISP:FIRST and LISP:REST in the package SET, and says "Go through all the definitions in your set file; make sure to type lisp:first and lisp:rest explicitly wherever necessary." (Some previous definitions in that file used first and rest.) In Medley, no definitions need to be changed, as they are automatically forwarded to CL:FIRST and CL:REST when those functions are shadowed and redefined.