>>>>> "Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> What would be more interesting (to me, at least) than knowing what
Kent> implementations do would be knowing whether anyone has run into any
Kent> problems where they used *print-readably* in any of these behaviors
Kent> expecting to be protected and ended up not protected. I would bet that
Kent> if people are following the proper print/read consistency guidelines,
Kent> they're adequately protected under any of the cited behaviors above.
Kent> But empirical data confirming or denying that would be good to have.
The particular case I had in mind was f2cl which creates Lisp code
from Fortran. Assuming default values for all printer control vars,
f2cl will generate code like
(let ((x 42.0))
(declare (single-float x))
...)
If I should now compile and load this into Lisp but had
*read-default-float-format* set to 'double-float, then x is
initialized to a double-float, which contradicts the declaration.
I thought setting *print-readably* to T would cause f2cl to print 42.0
as 42f0 so that compiling the file would produce the right result.
But you are right---there are lots of implicit assumptions when
printing and reading. The only way to be sure is to agree on the
settings when printing and reading and make them consistent.
However, I find it conceptually nice if *print-readably* tried to
print things such that the impact of these implicit assumptions were
minimized.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> The particular case I had in mind was f2cl which creates Lisp code
> from Fortran. Assuming default values for all printer control vars,
> f2cl will generate code like
>
> (let ((x 42.0))
> (declare (single-float x))
> ...)
>
> If I should now compile and load this into Lisp but had
> *read-default-float-format* set to 'double-float, then x is
> initialized to a double-float, which contradicts the declaration.
This is why I asked. You are violating the print/read rules if you don't
read the object with a compatible set of variable bindings to what you
printed it with.
In my personal opinion, it's not *print-readably*'s job to check that
you have that reader environment set up at print time. It's instead its
job merely to assure that it's printing things in a way that are consistent
with relevant printer control settings (which includes some, but not all
reader settings) such that re-reading is plausible.
*read-default-float-format* is a reader variable, but affects printing,
so I think you have to have it consistently bound. But *print-base* exists
for the precise purpose of saying "this is the base I will use on read".
Otherwise, we'd have just had a *print-and-read-base* which is used
both for the printer and reader. In that case, I personally don't think it's
*print-readably*'s job to say "you must bind an extra special variable here
even though it will not be used for anything during the printing". That just
takes time to bind and slows down multiprocessing (which has to bind/unbind
the special on every stack group switch) gratuitously.
> I thought setting *print-readably* to T would cause f2cl to print 42.0
> as 42f0 so that compiling the file would produce the right result.
In an implementation with only one floating format, for example, there'd
never be any reason to print the marker. *print-readably* is only about
re-reading in the same implementation, not across implementations. (maybe
that's a bug, but that's the definition.) And I think it's reasonable for
the printer to assume you'll bind the thing to the same value on read, so
even if you do have a distinct single and double format, if you have it
bound to double on printing and print a double, i think it's fair for the
system to expect you'll bind to double on read, so again it doesn't need
the marker.
> But you are right---there are lots of implicit assumptions when
> printing and reading. The only way to be sure is to agree on the
> settings when printing and reading and make them consistent.
Glad we agree on this.
> However, I find it conceptually nice if *print-readably* tried to
> print things such that the impact of these implicit assumptions were
> minimized.
It also has other things to worry about.
- efficiency - it's easy to slow down the printer A LOT if not careful
- correctness - when I say (write n :radix 7), you'd better have a darned
good reason not to write it in radix 7. i didn't just pick that number
casually.
The end result is a balance of many issues--not just a matter of the
simple application of "conservative principles" to an otherwise unconstrained
space.
>>>>> "Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> In my personal opinion, it's not *print-readably*'s job to check that
Kent> you have that reader environment set up at print time. It's instead its
Kent> job merely to assure that it's printing things in a way that are consistent
Kent> with relevant printer control settings (which includes some, but not all
Kent> reader settings) such that re-reading is plausible.
At least by putting an exponent marker, re-reading is "more"
plausible.
Kent> In an implementation with only one floating format, for example, there'd
Kent> never be any reason to print the marker. *print-readably* is only about
Kent> re-reading in the same implementation, not across implementations. (maybe
Kent> that's a bug, but that's the definition.) And I think it's reasonable for
Kent> the printer to assume you'll bind the thing to the same value on read, so
Kent> even if you do have a distinct single and double format, if you have it
Kent> bound to double on printing and print a double, i think it's fair for the
Kent> system to expect you'll bind to double on read, so again it doesn't need
Kent> the marker.
If I somehow implied writing with one implementation and reading from
another, I was wrong. I am only looking at one implementation.
However, by your argument, I wouldn't have to bind *print-readably* to
anything to get floating-point numbers read back in correctly since
everything is supposed to be bound to the same thing at print and read
time.
Kent> - efficiency - it's easy to slow down the printer A LOT if not careful
True. I was only concerned with printing out floating-point numbers
and I think that efficiency is not an issue here. (FP printing is
already slow.) I have not considered the consequences for other
objects.
Kent> - correctness - when I say (write n :radix 7), you'd better have a darned
Kent> good reason not to write it in radix 7. i didn't just pick that number
Kent> casually.
Presumably, you also wanted *print-readably* bound to T in this case.
If not, then I don't see the issue there since it doesn't have to be
readable. Well, as someone pointed out in the CMUCL list, this could
be printed as #7r<nnn> in this case. Satisfies the spirit if not the
letter. :-)
Kent> The end result is a balance of many issues--not just a
Kent> matter of the simple application of "conservative
Kent> principles" to an otherwise unconstrained space.
Yes. *print-readably* is not clearly specified, and that's the way it
is. Wishing it were won't make it so. :-(
Ray
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> wrote:
>However, by your argument, I wouldn't have to bind *print-readably* to
>anything to get floating-point numbers read back in correctly since
>everything is supposed to be bound to the same thing at print and read
>time.
IMHO, the main purpose of *PRINT-READABLY* is to catch you when you try to
print things that don't have any readable printed representation,
i.e. objects that print using #<...> notation. However, as an added
convenience, it also overrides variables like *PRINT-ESCAPE* and
*PRINT-GENSYM*, which control whether objects are printed in a readable
form, so you only have to set this one variable to get all their effects.
A number is readable in any base, so *PRINT-READABLY* isn't required to
force a specific base.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
>>>>> "Barry" == Barry Margolin <······@genuity.net> writes:
Barry> In article <··············@rtp.ericsson.se>,
Barry> Raymond Toy <···@rtp.ericsson.se> wrote:
>> However, by your argument, I wouldn't have to bind *print-readably* to
>> anything to get floating-point numbers read back in correctly since
>> everything is supposed to be bound to the same thing at print and read
>> time.
Barry> IMHO, the main purpose of *PRINT-READABLY* is to catch you when you try to
Barry> print things that don't have any readable printed representation,
Barry> i.e. objects that print using #<...> notation. However, as an added
Barry> convenience, it also overrides variables like *PRINT-ESCAPE* and
Barry> *PRINT-GENSYM*, which control whether objects are printed in a readable
Barry> form, so you only have to set this one variable to get all their effects.
If the assumption is that the print state and the read state are
intended to be consistent, then this seems to be the real (and only?)
purpose of *print-readably*. Since experts like you and Kent agree on
this point, who am I to disagree? :-)
Barry> A number is readable in any base, so *PRINT-READABLY* isn't required to
Barry> force a specific base.
But the number that is read has to be similar to the number that is
printed, so the bases do matter if they're different. But then the
print and read states aren't consistent, so perhaps this is
irrelevant.
Ray
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> wrote:
>>>>>> "Barry" == Barry Margolin <······@genuity.net> writes:
> Barry> A number is readable in any base, so *PRINT-READABLY* isn't
>required to
> Barry> force a specific base.
>
>But the number that is read has to be similar to the number that is
>printed, so the bases do matter if they're different. But then the
>print and read states aren't consistent, so perhaps this is
>irrelevant.
Right. Even without setting *PRINT-READABLY*, there's already the
requirement that reading a number will result in a number that's similar to
the number that was printed. In either case, this requirement is only in
effect if the number-related printer control variables are consistent.
I agree that this isn't clear in the standard. The ambiguity implies that
you must set these variables consistently, because the standard doesn't
guarantee that the right thing will happen otherwise.
Good rule of thumb when dealing with standards: assume the worst when
something is unclear. If something can possibly be interpreted in multiple
ways, there's a chance that different implementors will have chosen
different interpretations. If you can, avoid writing code that depends on
a particular interpretation. If you've seen my posts about when I think
LOOP is inappropriate, it's based on this principle (there's some known
ambiguity in the interaction between different LOOP keywords, so I
recommend avoiding complex combinations).
Perhaps things like this can be corrected in an update to the standard, but
then you still will have to deal with older implementations for a while. I
realize this sounds very cynical about the value of standards, but I don't
intend that. Most of the things you need to write commonly are pretty well
specified, but occasionally you run into corners that we weren't able to
specify as fully as necessary, either because we didn't notice the problem
or we simply ran out of time.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> IMHO, the main purpose of *PRINT-READABLY* is to catch you when you try to
> print things that don't have any readable printed representation,
> i.e. objects that print using #<...> notation.
Mine, too.
> However, as an added
> convenience, it also overrides variables like *PRINT-ESCAPE*
"One man's trash is another man's treasure."
Personally I hate that it overrides *PRINT-ESCAPE*.
I have tones of legacy programs that do (IF *PRINT-ESCAPE* ...)
and which are not sensitive to *PRINT-READABLY* and I often just
forget to put in the mention of *PRINT-READABLY* on new ones.
I think people should bind both. I think *PRINT-READABLY* should
describe the action of PRIN1, not force PRIN1 to occur.
> and
> *PRINT-GENSYM*, which control whether objects are printed in a readable
> form, so you only have to set this one variable to get all their effects.
But you hve to *test* several variables.
> A number is readable in any base, so *PRINT-READABLY* isn't required to
> force a specific base.
Right.
Moreover, since PRIN1 and PRINC on numbers do the same thing, one
would think that WRITE, which is neutral as to *PRINT-ESCAPE* when dealing
with numbers, would be the function to call when writing a number. Saves
fussing over a non-choice between PRIN1 and PRINC. Yet, if *PRINT-READABLY*
were to change what base things came out in, then WRITE would not be the
function to call in most number situations.
Kent M Pitman <······@world.std.com> writes:
> The end result is a balance of many issues--not just a matter of the
> simple application of "conservative principles" to an otherwise unconstrained
> space.
Maybe instead of just a boolean special controlling this, it should
instead be
(declare (readability 2) (efficiency 3) (correctness 1))
so that you could do cool math on it and surprise users with the
"necessary" outcome.
From: Barry Margolin
Subject: Re: *print-readably* and printing numbers
Date:
Message-ID: <dueI6.9$Ip3.310@burlma1-snr2>
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> wrote:
>But you are right---there are lots of implicit assumptions when
>printing and reading. The only way to be sure is to agree on the
>settings when printing and reading and make them consistent.
And this is the purpose of WITH-STANDARD-IO-SYNTAX. If you use this around
both the writing and reading code, you know that they'll be consistent.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <···············@burlma1-snr2>,
Barry Margolin <······@genuity.net> writes:
> In article <··············@rtp.ericsson.se>,
> Raymond Toy <···@rtp.ericsson.se> wrote:
>>But you are right---there are lots of implicit assumptions when
>>printing and reading. The only way to be sure is to agree on the
>>settings when printing and reading and make them consistent.
>
> And this is the purpose of WITH-STANDARD-IO-SYNTAX. If you use this around
> both the writing and reading code, you know that they'll be consistent.
And how does the producer of a Lisp file ensure that all potential consumers
of that file will wrap WITH-STANDARD-IO-SYNTAX around READ/EVAL/COMPILE/...?
(The LispMs at least had the :BASE option in the file's atribute line.) Most
Lisp code I've seen, and written, makes the false assumption that *READ-BASE*
is set to 10. Or should that be #10r10?
I guess the answer is that one cannot use any of the standard Lisp I/O
functions if the type when read back in is important. In Ray's case, he
probably needs to write his own print-int, print-float, print-double, ...
routines that'll produce output that's not sensitive to the setting of any of
the various *READ-???* variables.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> And how does the producer of a Lisp file ensure that all potential consumers
> of that file will wrap WITH-STANDARD-IO-SYNTAX around READ/EVAL/COMPILE/...?
The reading party's job.
> (The LispMs at least had the :BASE option in the file's atribute line.)
Aside about LispM's: The variables in Maclisp were called IBASE and BASE.
IBASE controled the input base, and BASE controlled the output base. There
was no OBASE, though many felt BASE should have been named OBASE. The Lispm
has this same naming in Zetalisp, if memory serves. Curiously, in file syntax
lines, Base: xxx; controls the ibase, not the base. As I recall, it
specifically does not bind BASE, in spite of its name. So in cases of
Base: 8; I believe some confusion can arise. I remember sending a bug report
about this eons ago when I first noticed it, but I think by time people did
as I was doing, it was too late to fix--too many things relying on current
behavior. So this is not a "new" problem...
> most
> Lisp code I've seen, and written, makes the false assumption that *READ-BASE*
> is set to 10. Or should that be #10r10?
I'm glad they do assume that. You have no idea how hard-fought this
little victory was. I waged a multi-year war many (though not all)
well-known lispers while at MIT who insisted that the default base of
8 in Maclisp and Zetalisp was the "right" base, that 8 was just purer
and better. We used to get regular bug reports that + was broken
because (+ 5 5) => 12, and the FAQ used to have to explain that + was
not broken, etc.
Today's problems are different than that, and I suppose that is the
quality of progress--not that things get fixed forever, but that we
move on eventually from one problem to whine about to another problem
to whine about.
Some day I hope to publish my notes on this conversation about why
base 8 was better. It was a fascinating discussion, and I hope with
the benefit of some time between then and now will come across as
appropriately humorous, even by those who stuck to 8.
> I guess the answer is that one cannot use any of the standard Lisp I/O
> functions if the type when read back in is important.
This ignores everything we have been saying.
The answer is that one can use any of the standard Lisp I/O functions if the
type when read back in is important, and the way you demonstrate that you
care enough to see this happen is you reproduce the appropriate environment.
If you don't do your part, why should the system do its part??
> In Ray's case, he
> probably needs to write his own print-int, print-float, print-double, ...
> routines that'll produce output that's not sensitive to the setting of any of
> the various *READ-???* variables.
NO. There are several *read-xxx* variables that are documented to
have an effect on both the printer and reader. See 22.1.1.1 (Multiple
Possible Textual Representations) where they are enumerated.
If you bind these properly, the normal I/O functions will do the right
thing.
Kent M Pitman <······@world.std.com> writes:
> I'm glad they do assume that. You have no idea how hard-fought this
> little victory was. I waged a multi-year war many (though not all)
> well-known lispers while at MIT who insisted that the default base
> of 8 in Maclisp and Zetalisp was the "right" base, that 8 was just
> purer and better. We used to get regular bug reports that + was
> broken because (+ 5 5) => 12, and the FAQ used to have to explain
> that + was not broken, etc.
Hmm... I'd think that base 12 would be preferable, as it's got
factors of 2 and 3, thus making it possible to represent more values
exactly.
Mind you, base 2x3x5x7, or 210, is less than 255, nicely fitting into
a byte, and is divisible by all those lovely primes... 210 seems a
nice base to play with...
--
(reverse (concatenate 'string ····················@" "454aa"))
http://vip.hex.net/~cbbrowne/resume.html
Now is a good time to spend a year dead for tax purposes.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> And how does the producer of a Lisp file ensure that all potential consumers
>> of that file will wrap WITH-STANDARD-IO-SYNTAX around READ/EVAL/COMPILE/...?
>
> The reading party's job.
And how is the reader suppose to know the "correct" settings? How does the
writer of a lisp file ensure that whoever calls LOAD or COMPILE-FILE has set
the variables correctly?
>> most
>> Lisp code I've seen, and written, makes the false assumption that *READ-BASE*
>> is set to 10. Or should that be #10r10?
>
> I'm glad they do assume that. You have no idea how hard-fought this
> little victory was.
Actually, I do. I've been around long enough to have to deal with the
default base being 8. At least in the ZetaLisp days there was a method to
ensure the read base was consistant with the base used when writing the file.
That's not the case today.
>> I guess the answer is that one cannot use any of the standard Lisp I/O
>> functions if the type when read back in is important.
>
> This ignores everything we have been saying.
>
> The answer is that one can use any of the standard Lisp I/O functions if the
> type when read back in is important, and the way you demonstrate that you
> care enough to see this happen is you reproduce the appropriate environment.
But as a writer, you don't have control over the read environment. That's
some other user's environment. Maybe he's a ZetaLisp fan and has *read-base*
set to 8. Maybe it's cbrown's environment and he has it set to 210 (decimal).
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> writes:
> > ·······@mikemac.com (Mike McDonald) writes:
> >
> >> And how does the producer of a Lisp file ensure that all potential consumers
> >> of that file will wrap WITH-STANDARD-IO-SYNTAX around READ/EVAL/COMPILE/...?
> >
> > The reading party's job.
>
> And how is the reader suppose to know the "correct" settings? How does the
> writer of a lisp file ensure that whoever calls LOAD or COMPILE-FILE has set
> the variables correctly?
I don't understand. Most input to LOAD or COMPILE is not generated by print.
But it's trivial if you are auto-generating a file to have boilerplate at
the front that does any necessary checks. e.g.,
(eval-when (:compile-toplevel :execute)
(unless (= *read-base* 10.) ...)
...)
> >> most
> >> Lisp code I've seen, and written, makes the false assumption that *READ-BASE*
> >> is set to 10. Or should that be #10r10?
> >
> > I'm glad they do assume that. You have no idea how hard-fought this
> > little victory was.
>
> Actually, I do. I've been around long enough to have to deal with the
> default base being 8. At least in the ZetaLisp days there was a method to
> ensure the read base was consistant with the base used when writing the file.
> That's not the case today.
>
> >> I guess the answer is that one cannot use any of the standard Lisp I/O
> >> functions if the type when read back in is important.
> >
> > This ignores everything we have been saying.
> >
> > The answer is that one can use any of the standard Lisp I/O functions if the
> > type when read back in is important, and the way you demonstrate that you
> > care enough to see this happen is you reproduce the appropriate environment.
>
> But as a writer, you don't have control over the read environment.
No, that's not true. You do have the ability to use notations that
are safe, assuming you have Lisp looking at your code at all. The
radixed things like 10. and #xAA are safe. You can use these to get a
foothold and make sure that things are safe, if you doubt it.
> That's some other user's environment. Maybe he's a ZetaLisp fan and
> has *read-base* set to 8. Maybe it's cbrown's environment and he has
> it set to 210 (decimal).
That you can't control the read environment is not something
lamentable, it is a fundamental property of the universe. Lamenting
things that are intrinisic to the universe is possible, I suppose, but
pointless. You'll never have 100% assurance someone won't try to read
your file as Teco. At some point, you'll just have to trust. So while
trusting the person will respect the fact that you've documented your file
to want to be interpreted by Lisp, why not trust them to do the rest
of the things you say you have to do.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> In article <···············@world.std.com>,
>> Kent M Pitman <······@world.std.com> writes:
>> > ·······@mikemac.com (Mike McDonald) writes:
>> >
>> >> And how does the producer of a Lisp file ensure that all potential consumers
>> >> of that file will wrap WITH-STANDARD-IO-SYNTAX around READ/EVAL/COMPILE/...?
>> >
>> > The reading party's job.
>>
>> And how is the reader suppose to know the "correct" settings? How does the
>> writer of a lisp file ensure that whoever calls LOAD or COMPILE-FILE has set
>> the variables correctly?
>
> I don't understand. Most input to LOAD or COMPILE is not generated by print.
But that's precisely what Ray's question is about, f2cl! He's using lisp to
write lisp code, to be read back in in some environment that he doesn't
control.
>> But as a writer, you don't have control over the read environment.
>
> No, that's not true. You do have the ability to use notations that
> are safe, assuming you have Lisp looking at your code at all. The
> radixed things like 10. and #xAA are safe. You can use these to get a
> foothold and make sure that things are safe, if you doubt it.
And how do you force the standard print routines to include the appropriate
radix info? In my opinion, the answer should be by setting *print-readably* to
T. Otherwise there is no way using the standard print routines.
Mike McDonald
·······@mikemac.com
In article <··················@typhoon.aracnet.com>,
·······@mikemac.com (Mike McDonald) writes:
I'm starting to rant again and mix several different issues together.
(integers vs floats, radix vs exponents) So let me try another approach.
The spec for *PRINT-READABLY* says:
----
If *print-readably* is true, some special rules for printing objects
go into effect. Specifically, printing any object O1 produces a printed
representation that, when seen by the Lisp reader while the standard readtable
is in effect, will produce an object O2 that is similar to O1. The printed
representation produced might or might not be the same as the printed
representation produced when *print-readably* is false. If printing an object
readably is not possible, an error of type print-not-readable is signaled
rather than using a syntax (e.g., the ``#<'' syntax) that would not be
readable by the same implementation. If the value of some other printer
control variable is such that these requirements would be violated, the value
of that other variable is ignored.
----
Let's start with printing floats first. The definition of similar numbers is:
3.2.4.2.2 - Two numbers S and C are similar if they are of the same type and
represent the same mathematical value.
I believe the important part is the phrase "they are of the same type"! To
me, that means that when a float is printed out with *PRINT-READABLY* set to
true, it has to be done in such a way that when read in by the same
implementation, it'll produce a float with the same type. I believe that the
value of *READ-DEFAULT-FLOAT-FORMAT* should be ignored because depending upon
its value to be the same at both print and read times would violate the
requirement that the read in number represent the same mathematical value and
type as the original value.
In the case of integers, relying on the value of "some other printer control
variable", aka *READ-BASE*, instead of including the radix information can
cause the read in number to have a completely different mathematical value. I
can't see how that meets the similarity requirement. My interpretation is that
if *PRINT-READABLY* is true, printing proceeds as if *PRINT-RADIX* was also
true.
Mike McDonald
·······@mikemac.com
In article <··················@typhoon.aracnet.com>,
Mike McDonald <·······@mikemac.com> wrote:
>In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> writes:
>> ·······@mikemac.com (Mike McDonald) writes:
>>
>>> And how does the producer of a Lisp file ensure that all potential consumers
>>> of that file will wrap WITH-STANDARD-IO-SYNTAX around READ/EVAL/COMPILE/...?
>>
>> The reading party's job.
>
> And how is the reader suppose to know the "correct" settings? How does the
>writer of a lisp file ensure that whoever calls LOAD or COMPILE-FILE has set
>the variables correctly?
Either don't mess with the global settings of the variables at all, or wrap
whatever you're doing in WITH-STANDARD-IO-SYNTAX, e.g.
(with-standard-io-syntax
(compile-file ...))
I think anyone who modifies the global settings of variables like
*READ-BASE* will soon learn the error of their way, since lots of things
will probably break. If you're writing a program that creates a file that
will be read by someone else, the best you can do is write it in the
standard I/O environment and expect them to read it in the same
environment.
If you want to go further, put something in your documentation saying that
this is necessary. But since this is necessary for just about everything,
it's generally considered the reader's problem, not yours.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.