Hello, On Mon, Apr 22, 2013 at 4:39 PM, Andy Wingo <wi...@pobox.com> wrote:
> Hi :) > > Thanks for working on the RTL VM! > Thanks for doing most of the work! I'm happy to help. :-) > First of all, sorry about that linker error. I'm trying to make RTL > programs more debuggable by hacking on the linker, so that it emits > proper debugging information. I should have caught that typo though! > Debugging would be great. I have thought about stopping this and working on debugging stuff some, but that actually seems harder than what I'm doing now, and I would like to get the compiler working. > I think however that the strategy of making the VM somehow more > resilient is not going to work. There are so many ways that invalid > instructions can make the VM fail -- and you have no idea what you can > rely on if those invariants fail. So it doesn't seem to me that it's > possible to do that job well at all, and for that reason it seems to me > that we shouldn't try very hard. > I assume you're talking about the box-ref and box-set! stuff with checking for non-variables, right? I agree in general, but those instructions could plausibly be emitted for any code that uses module introspection to get its own variable objects, right?. At that point the not-a-variable error would be a user type error, and so I think it's better to throw wrong-type-arg. (But of course, that's not my real motivation - I just happened to hit this while debugging the compiler.) And I don't know how you've been able to get as far as you have with the > deplorable state of the debugging infrastructure. You can't even > disassemble a function you just made! I'll be working on that this > week; we'll see what happens. > > So in summary, dunno. Surely there is some way we can do things better, > but I wanted to register my skepticism for this line of hacking. What > do you think? > First of all, I agree that debugging infrastructure would be great. I'm very glad you're working on it - that should help a lot. I'm not sure if I have much to add there right now, but I will keep it in mind. As for the line of hacking, as I said above, I think in the particular case of box-ref and box-set! it's justified; I don't know in general. I certainly agree that once the VM's internal state is corrupt, all bets are off, and we probably won't be able to continue. 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? Best, Noah
