Hello,

On Tue, Apr 23, 2013 at 6:13 AM, Andy Wingo <wingo@pobox.com> wrote:

> Heya,
>
> On Tue 23 Apr 2013 04:38, Noah Lavine <noah.b.lavine@gmail.com> writes:
>
> Ah I see what you mean.  There are two uses of variables in the VM: one
> for calls to variable-ref or variable-set, and the other for internal
> use.  For the internal uses, we know the variable should indeed be a
> variable and so we should emit the checks.  For calls to variable-ref /
> variable-set, I think it would be best if somehow the compiler could
> replace those calls with (if (call variable? x) (primcall box-ref x)
> (call error ...)).  Dunno.  WDYT?
>

Do we usually omit checks for internal stuff? If so, I agree, we should do
that here too. But right now we do the check every time anyway - the only
difference my patch made is whether we failed with abort() or
vm_error_not_a_variable.

I agree that that doesn't make much sense as an error for internal stuff.
Maybe change it to vm_error_bad_instruction or something like that for now?
In general I agree that we should be able to do nice error checking only
for user-generated box-refs, but that seems more complex than we need right
now (unless you want to add it to the VM).


> > One thing that would be interesting - and I don't know if we do this
> > now - is using different VMs for different parts of the
> > code. Specifically, if the REPL ran in a different VM than user code,
> > then the REPL wouldn't die in these cases.  That might also enable
> > cool debugging things, like single-stepping the user VM and examining
> > its registers. I noticed that we already have support for changing the
> > active VM. What do you think?
>
> We can do that already to a degree... probably the best "fallback" that
> we have is the stack VM, actually.  What happens if you install traps on
> the VM that call stack VM procedures and then you run an RTL function?
> I would think that you should be able to do something useful there.
>

That does sound interesting, but I've never used traps. I've been meaning
to learn them some time so I can try to remember tail calls for debugging,
but that probably won't be for a little while.

Noah