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 15:21 UTC

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

On 09/30/2011 03:26 PM, xacc.ide@gmail.com wrote:
>
>> Scheme48/scsh is the only implementation that does (fail)
>
> IronScheme fails, and will fail every one of these funky eval examples you
> have provided.
>
> I find it disturbing that eval should be anything more than an interface to
> the compiler.

eval being an interface to a compiler is fine. What we're discussing is
a change that, some say, might disallow that compiler being in a
different address space...

However, when we eval '(cons 1 2), we might expect that the cons it
invokes is the same cons used by the rest of our code (ok, cons being
tiny might be inlined - let's imagine that it's something bigger like
eval itself), rather than a new copy created by a remote compiler. Even
more so if the eval-ed code imports a large, complex, library that is
already used in the main program. So the eval->compiler->eval interface
would need some way of resolving such references to shared resources,
which can presumably also be applied to references via the eval-ed
sexpression itself.

If all else fails, you can surely map:

(eval '( ... <unprintable literal> ...))

into something like:

((eval '(lambda (<gensym>) ( ... <gensym> ...))) <unprintable literal>)

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/

iEYEARECAAYFAk6F3mMACgkQRgz/WHNxCGq3NACfQFJVvcGuZ1s++94RTEB21xH0
uEMAoIb2TfeHKO7mahUCoS/z+uG0cArV
=YF0v
-----END PGP SIGNATURE-----

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