[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New mis-feature of TOPS-20, Release 5, and/or search rules for Logical names



Problems with logical names under Twenex have come up in the past,
and the new state, having PS: be a 'logical name', will break MacLISP.
Since it is now installed on SCORE that way, then SCORE's MacLISP
will essentially be unusable until there is some resolution -- I don't
yet know of other sites with Release 5 yet, so maybe we can 'fix' this
before too many others are affected.  

One fix I suggested is having MacLISP 'special-case' the PS: device, but
that amounts to defeating this new misfeatureful generality and I'm not
sure that that's wise in the long run.   The only other alternative is
for the searching rules to act in accord with my suggestion below, which 
is part of my reply to your reply:

    Date: 17 Nov 1981 1519-PST
    From: Mark Crispin <Admin.MRC at SU-SCORE>
    In-Reply-To: Your message of 17-Nov-81 1130-PST
    . . . 
    Yes, the systemwide logical name of PS: is a new feature of TOPS-20. . . 
    The bug is MACLISP's.  It should supply both the device and the directory
    specification to GTJFN in all circumstances.  
This doesn't work -- when the GTJFN supplies a directory specification,
it overrides any such in the logical name.  E.g., suppose you have
@DEF FOO: PS:<JONL>,PS:<MACLISP>
and suppose <MACLISP> has a BS.LSP, but <JONL> doesn't.  Then using
"FOO:BS.LSP" will succeed, but "FOO:<JONL>BS.LSP" will not.  I suspect
that in the latter case, the "FOO:" part is limited to supplying a real
device name (i.e., PS:) for the searching procedure, whereas it should
go through its search sequence independently of the <JONL>.  The MacLISP
user will find himself 'supplying' directory specifications without 
conscious effort, since that is the reason for the DEFAULTF variable;  
possibly initializing it to ((* *) * ...)  would get around some problems, 
but may introduce other undesirable perturbations.

						  If it needs the true location
    of the file, it should GTJFN it with GJ%OLD (to force a chase down the
    logical name tree to find an existing file) then use JFNS to get the string
    back.

That's indeed how the PROBEF and TRUENAME functions work.

    Release 5 is going to be this way as a standard.

HELP!  Any of you Twenex wizards out there got an idea?