[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


>