Re: [Scheme-reports] Current tickets for the 5th ballot Andy Wingo (29 Sep 2011 08:39 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot John Cowan (29 Sep 2011 15:44 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot Andy Wingo (29 Sep 2011 16:13 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot Aaron W. Hsu (29 Sep 2011 16:20 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot Andre van Tonder (29 Sep 2011 16:30 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot Per Bothner (29 Sep 2011 16:33 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot Andy Wingo (29 Sep 2011 17:15 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 Andre van Tonder (29 Sep 2011 16:26 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 Alaric Snell-Pym (30 Sep 2011 08:36 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 Andre van Tonder (30 Sep 2011 12:51 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 Alaric Snell-Pym (30 Sep 2011 12:53 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 xacc.ide@gmail.com (30 Sep 2011 14:27 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 xacc.ide@gmail.com (30 Sep 2011 15:16 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 Alaric Snell-Pym (30 Sep 2011 15:21 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 xacc.ide@gmail.com (30 Sep 2011 15:36 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 Alaric Snell-Pym (30 Sep 2011 13:10 UTC)
Re: [Scheme-reports] Current tickets for the 5th ballot - 281 Alaric Snell-Pym (30 Sep 2011 13:14 UTC)

Re: [Scheme-reports] Current tickets for the 5th ballot Per Bothner 29 Sep 2011 16:32 UTC

On 09/29/2011 09:12 AM, Andy Wingo wrote:
> On Thu 29 Sep 2011 17:43, John Cowan<cowan@mercury.ccil.org>  writes:
>
>> Andy Wingo scripsit:
>>
>>>> #281 Make non-readable objects self-quoting in EVAL
>>>
>>> Unless I misunderstand, this effectively requires that `eval' is an
>>> interpreter and not a compiler.  Is that your intention?
>>
>> Not at all.  It simply means that if you pass EVAL a list of the form
>> (#<procedure +>  1 2), it is treated as if it were of the form
>> ('#<procedure +>  1 2).  Guile currently accepts the latter but not the
>> former.
>
> The issue is not what Guile currently supports; it is about
> implementation strategies.  Currently it is valid to implement `eval' in
> terms of `compile'.  `compile' requires the ability to serialize objects
> to data, then to run that data on some machine, native or virtual.
> Scheme has not heretofore required serializability for arbitrary
> objects.

Presumably you would then also forbid ('#<procedure +>  1 2) - since
the serializability issue is the same?

Regardless, I don't share your concern (and I speak as the implementor
of one of the more compilation-focused Scheme implementations around).
I think there are solutions to the problem.  For example:
   (#<procedure +>  1 2)
could be "serialized" as:
   (#<literal-345> 1 2)
where #<literal-345> is some magic reader syntax that the compiler
translates into a reference to an index 345 into a "literal table",
which is not directly accessible to the compiler, but available
when the compiled code is evaluated.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports