simon-brooke / beowulf Goto Github PK

There's something subtle wrong with association lists in COPY, although it's likely that the real problem is in the reader and COPY is just where it's showing up.

Two tests characterise this bug:

1. copy assoc list created in READ fails, copying ((A . 1) (B . 2) (C . 3)) as ((A) (B) (C));
2. copy assoc list created with PAIR succeeds, although the source list should be exactly the same as in the other test.

It's currently impossible to edit the input line (other than deleting back and retyping) or to recall previous input lines to edit or redo. I'd really like to be able to do this directly in the new Lisp reader, but that means being able to detect and act on individual key-strokes, and that is really not at all easy on anything that runs on a JVM.

A good compromise would be to extend the work I've already started in beowulf.reader.char-reader of leveraging JLine; but JLine is now very complex and I do not find its documentation at all perspicuous.

What is needed, at minimum, is

1. Carriage return does not cause input to be returned, unless
   a. the number of open brackets ( and closing brackets ) match; and
   b. the number of open square brackets [ and closing square brackets ] also match;
   2. <Ctrl-D> aborts editing and returns the string STOP;
   3. <up-arrow> and <down-arrow> scroll back and forward through history, but ideally I'd like
   this to be the Lisp history (i.e. the history of S-Expressions actually read by READ,
   rather than the strings which were supplied to READ);
   4. <tab> offers potential auto-completions taken from the value of (OBLIST), ideally the
   current value, not the value at the time the session started;
   5. <back-arrow> and <forward-arrow> offer movement and editing within the line.

Quite serious because it means DEFUN doesn't work.

I think what's happening is that it breaks if the symbol to which the property is being attached does not yet exist.

It's close... it's so close ...

I do not understand how property lists worked in Lisp 1.5.

There are several ways I can hack it, but I need to understand and to get it right. There was something intrinsic to an ATOM that gave it another pointer.

Was an ATOM in fact an object in cons-space (so the size of a cons cell) whose CAR pointed to a vector of characters and whose CDR was otherwise unused? Studying the assembly language in Appendix A may help here.

I've not been very consistent with keys in ex-info. For better, more consistent, error reporting, these need to be more consistent.

Keys which seem to make sense are

1. :phase -- in what phase of the REPL was this error detected? Valid phases seem to me
   1. :parse ;
   2. :simplify;
   3. :generate;
   4. :eval;
   5. :apply;
   6. :lisp -- errors detected and thrown with the ERROR function in Lisp code;
   7. :host -- errors detected and thrown in host functions (i.e. functions implemented in beowulf.host);
2. :function -- the actual Lisp or host function which was being evaluated when the error occurred;
3. :args -- what args were passed to that function;
4. :type -- whether this is a failure in my implementation of Lisp 1.5, or a failure in user code? For example, division by zero is a user code issue. There is a table on pages 32-34 of the manual which gives the errors reported by Lisp 1.5 and their associated codes (one letter, one number). I think these types should be expressed as:
   1. :lisp -- an error specified in the manual, or which it is reasonable to suppose would have been reported as an error by Lisp 1.5;
   2. :beowulf -- an error in my implementation;
   3. :strict -- an error caused by beowulf being in strict mode;
5. :code -- if it is of type :lisp, the code specified in the table on pages 32-34.

I really have no handle on how I'm going to implement PROG and GO. I don't even really have a good idea of how jump targets were notated in the S-Expression syntax of List 1.5, although I'm guessing it was identical to how they were notated in Portable Standard Lisp.

This is definitely going to be tricky.