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 Aaron W. Hsu 29 Sep 2011 16:20 UTC

On Thu, 29 Sep 2011 12:12:49 -0400, Andy Wingo <wingo@pobox.com> 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.

I'm not sure that I disagree, however, it should be noted that Chez Scheme
also allows this behavior, and the COMPILE procedure in Chez Scheme allows
this behavior. In particular, when running Chez Scheme, all expressions in
EVAL are compiled before they are evaluated by default.

	Aaron W. Hsu

--
Programming is just another word for the lost Art of Thinking.

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