[plt-scheme] Self evaluating "objects"
----- Original Message -----
From: "Cristian Baboi" <cristian.baboi at gmail.com>
To: "Jos Koot" <jos.koot at telefonica.net>; <plt-scheme at list.cs.brown.edu>
Sent: Monday, July 14, 2008 2:34 PM
Subject: Re: [plt-scheme] Self evaluating "objects"
> On Mon, 14 Jul 2008 13:01:10 +0300, Jos Koot <jos.koot at telefonica.net>
> wrote:
>
>> Why bother about eval?
>
> Why not ?
>
>> Nevertheless:
>>
>> From:
>> http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-17.html#node_idx_1266
>> See also: http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-4.html#node_idx_52
>
> I've read those.
>
> "A *SUBSET* of the Scheme objects is called datum values. These *INCLUDES*
> booleans, number objects, characters, symbols, and strings as well as
> lists and vectors whose elements are data. Each datum value may be
> represented in textual form as a syntactic datum, which can be written out
> and read back in without loss of information."
>
>
>> In #lang scheme and mzscheme and pretty-big the value of a procedure is
>> that procedure. There is #!r6rs though, but:
>
>
>> #!r6rs
>> (library (aap)
>> (export)
>> (import (rnrs eval (6)) (rnrs base (6)) (rnrs io simple (6)))
>> (write (eval (lambda (x) x) (environment '(rnrs base (6))))))
>>
>> writes #<procedure>, which seems not to conform to R6RS, for a procedure
>> is not a datum value.
>
> It seems so, but the subset called "datum values" is not written in the
> sections you quoted.
The second reference does describe the notion of "datum values". It does not
require a procedure to be a datum value.
> Nevertheless it seems that the test "which can be written out and read
> back in without loss of information" fail for procedures.
That is common to all Scheme implementations I know of. It is not too
difficult to prepare a scheme *like* interpreter that internally represents
all procedures and syntaxes by symbolic expressions, their environments
included (but continuations excepted, that's a problem I did not yet solve;
and of course such an interpreter has to offend against the rule of disjoint
types; if a procedure is a symbolic expression, then it is not disjoint from
symbolic expressions) Such an interpreter would be a toy rather than a
useful tool.
Jos
>