this doesn't have much to do with any new monitor, I suspect

[Robert W. Kerns <RWK at MIT-MC>]

    Date: Tuesday, 13 January 1981  13:22-EST
    From: Chris Ryland <CPR at MIT-EECS>
    To: bug-lisp at mc
    Subject: this doesn't have much to do with any new monitor, I suspect
    cc: Keshav at MIT-XX
    
    Date: Monday, 12 January 1981  17:03-EST
    From: KESHAV at MIT-XX
    To:   cpr at MIT-XX
    Re:   A Bug
    
    The function writeablep in Maclisp is defined in the fasl file <maclisp>purep.
    fasl. My guess is that it checks for write protection violations. Until
    yesterday, calling this function with an output file (in Maclisp) gave t(rue).
    It still does so in Maclisp on ML. However, your new monitor gives a
    write protection error.
	  One LISP program that shows this is -
	   (load '((dsk maclisp) purep fasl))
	   (setq outfilep (open '(my output) 'out))
	   (writeablep outfilep)
       This should return t.

Your example looks suspsiously like you think WRITEABLEP has something
to do with files.  It does not.  It's purpose is to determine if
operations like RPLACA will result in a write-protection violation.
I.e.E WRITABLEP should return T for INPUT files as well, because
file-arrays are never placed on unwritable pages.  I cannot conceive of
a situation where you would legitamately be calling WRITABLEP on a file.

It is true, however, that WRITEABLEP does not yet work on TOPS-20.  (It
never did, and if you think it did you're wrong).  However, you can
write an acceptable substitute of (DEFUN WRITABLEP (X) (NOT (PUREP X))).