Issue: IN-SYNTAX?

[Jon L White <jonl@lucid.com>]

re: The fact that there are several variables like this that people tend to
    overlook is an argument for WITH-STANDARD-IO-ENVIRONMENT.

Right, which is why my first suggestion was to add an argument to LOAD that 
says "let the syntax be the current one, rather than the standard one".  

I have the feeling that taking the standard defaults is what 99.44% of 
all programs would be doing, and am thus willing to contemplate the more 
incompatible change to LOAD.  This would leave open a possibility for
a macro named something like WITH-STANDARD-INPUT-SYNTAX, which would 
dynamically bind the "standard" settings to the current values of the 
various documented parameters (or to keyword arguments).  The burden is 
thus shifted to the 0.56% of the cases that wanted something "non-standard".
I gathered from your reply to KMP that you don't think much of being able 
to dynamically bind the "standards".


re:     [jonl] As to [*read-default-float-format*], I don't have a great 
	  argument for it now, but I rather tend to view it as a global "site 
	  installation"  parameter, rather than as a useful dynamic variable; 
	  my mind would be changed if I heard of significant "dynamic" use.
    [moon] Outputting postscript.

Well, FORMAT's ~E or ~G with hairy prefix parameters could be used instead. 
[I presume you mean while PRINTing, rather than while READing; the READ side
is the important one for IN-SYNTAX.]  This looks like a gap in CL in that 
there is no corresponding parameter *PRINT-DEFAULT-FLOAT-FORMAT*; it's a bit 
like letting PRINT use *READ-BASE* rather than *PRINT-BASE*.   Were that 
corrected, then I think the conjecture about "site installation parameter" 
_might_ stand.



-- JonL --