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 - 281 Alaric Snell-Pym 30 Sep 2011 13:10 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/30/2011 02:07 PM, Alex Shinn wrote:
> On Fri, Sep 30, 2011 at 5:34 PM, Alaric Snell-Pym
> <alaric@snell-pym.org.uk> wrote:
>>
>> On 09/29/2011 05:25 PM, Andre van Tonder wrote:
>>
>>> On a system that that invokes a compiler on the argument of EVAL, the compiler
>>> may depend on the textual representation of the code '(cons 1 2).  It may even
>>> do certain optimizations and rewritings based on the textual representation.
>>> Again, having procedure objects in here confuses levels and can cause problems
>>> for such a compiler.
>>
>> Does it really? Can anyone point to an implementation of EVAL that can't
>> cope with this?
>
> Chicken's inline egg would not support this.  That's intended
> for inline C code, but could be modified and used as an EVAL
> replacement.

I'll discount that one, then, as it merely "could be" :-)

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6Fv8MACgkQRgz/WHNxCGpB0wCfZeMEgNOD3Zfbtv0tgenrMxaM
TU4An3ZLost6Sg8TKSjwsCRd6M6c88oe
=QHtD
-----END PGP SIGNATURE-----

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