[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: IN-SYNTAX?
- From: Jon L White <firstname.lastname@example.org>
- Date: Mon, 31 Oct 88 12:00:14 PST
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: David A. Moon's message of Fri, 28 Oct 88 19:38 EDT <19881028233810.0.MOON@EUPHRATES.SCRC.Symbolics.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"
-- JonL --