Per the dictionary entry for RANDOM-STATE:
Implementations are required to provide a read syntax for objects of
type random-state, but the specific nature of that syntax is
implementation-dependent.
And in 22.1.3.10 Printing Random States it says:
A specific syntax for printing objects of type random-state is not
specified. However, every implementation must arrange to print a
random state object in such a way that, within the same
implementation, read can construct from the printed representation a
copy of the random state object as if the copy had been made by
make-random-state.
Is there anything that prohibits an implementation from using #. in
the "read syntax" for RANDOM-STATE objects. In other words, will this
portably return a RANDOM-STATE object:
(let ((*read-eval* nil))
(read-from-string (write-to-string *random-state* :readably t)))
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Is there anything that prohibits an implementation from using #. in
> the "read syntax" for RANDOM-STATE objects. In other words, will this
> portably return a RANDOM-STATE object:
>
> (let ((*read-eval* nil))
> (read-from-string (write-to-string *random-state* :readably t)))
This is a tricky question. There is something of an assumption that
the printer is required to emit something that will be readable when
the standard syntax and standard syntax variable bindings are in
effect. (The exception, where the printer is required to read chicken
entrails about the current reader state, concerns case conversion.)
Consider that the printed representation of a random-state, while
implementation dependent, will probably contain lotsa numbers. So we
can rewrite your question this way:
(let ((*read-base* 3))
(read-from-string (write-to-string *random-state* :readably t)))
or maybe trickier:
(let ((s (write-to-string *random-state* :readably t)))
(let ((*read-base* 3))
(read-from-string s)))
Does this reflect anything on the issue?
Indeed, what is the implication of *print-readably? In your favorite
implementation do with this?
(write-to-string 22/7 :base 5 :readably t)
=====
Sorry -- Did I use the term "chicken entrails" earlier? I meant
"special variables" but I get these two concepts confused sometmies.
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Indeed, what is the implication of *print-readably? In your favorite
> implementation do with this?
>
> (write-to-string 22/7 :base 5 :readably t)
"#10r22/7" ;; clisp
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
"Steven M. Haflich" <·················@alum.mit.edu> wrote
> Indeed, what is the implication of *print-readably? In your favorite
> implementation do with this?
>
> (write-to-string 22/7 :base 5 :readably t)
ACL 6.2:
"42/12"
·············@swipnet.se (Peter Lewerin) writes:
>
> "Steven M. Haflich" <·················@alum.mit.edu> wrote
>
> > Indeed, what is the implication of *print-readably? In your favorite
> > implementation do with this?
> >
> > (write-to-string 22/7 :base 5 :readably t)
>
> ACL 6.2:
>
> "42/12"
Same for MCL 5.0 and openmcl 0.13.6
--
Thomas A. Russ, USC/Information Sciences Institute
Peter Seibel <·····@javamonkey.com> writes:
> Per the dictionary entry for RANDOM-STATE:
>
> Implementations are required to provide a read syntax for objects of
> type random-state, but the specific nature of that syntax is
> implementation-dependent.
>
> And in 22.1.3.10 Printing Random States it says:
>
> A specific syntax for printing objects of type random-state is not
> specified. However, every implementation must arrange to print a
> random state object in such a way that, within the same
> implementation, read can construct from the printed representation a
> copy of the random state object as if the copy had been made by
> make-random-state.
>
> Is there anything that prohibits an implementation from using #. in
> the "read syntax" for RANDOM-STATE objects.
Above it's written that read should be able to read random
states. Not that it should be able to read them only when the Moon is
full. (When you don't set *read-eval* to nil).
> In other words, will this
> portably return a RANDOM-STATE object:
>
> (let ((*read-eval* nil))
> (read-from-string (write-to-string *random-state* :readably t)))
I don't think so.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Pascal Bourguignon <····@mouse-potato.com> writes:
>> Is there anything that prohibits an implementation from using #. in
>> the "read syntax" for RANDOM-STATE objects.
>
> Above it's written that read should be able to read random
> states. Not that it should be able to read them only when the Moon is
> full. (When you don't set *read-eval* to nil).
>
>> In other words, will this
>> portably return a RANDOM-STATE object:
>>
>> (let ((*read-eval* nil))
>> (read-from-string (write-to-string *random-state* :readably t)))
>
> I don't think so.
Yup. I think you're right. And some implementations, such as SBCL, do
in fact use #.. Oh, well. I guess the best you can do is test whether
a given implementation uses #. via something like this:
(defun random-state-readable-without-eval-p ()
(not (typep
(nth-value 1
(ignore-errors
(let ((*read-eval* nil) (*print-readably* t))
(write-to-string *random-state*))))
'print-not-readable)))
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp