From: Calamitas Date: 2007-07-18T12:18:06+09:00 Subject: Re: Proposal: runtime-modifying Kernel methods should be keywords On 18/07/07, Ryan Davis wrote: > Wow this is getting frustrating. > > Did you even read what I said? > > "My POINT was that VARIOUS ASPECTS of hotspot (the ones that CAME > FROM SELF) do plenty for optimization in a COMPLETELY DYNAMIC WAY." > > There isn't a thing in self that is more restrictive than ruby. Quite > the opposite in fact. That was what I was referring to and yet you > sidestepped it and threw in another strawman argument. I'd be more > willing to continue this dialog and share my experience if I thought > you were listening and not just looking for something to shoot down. I think there are two concepts here that you both are mixing up. One is restriction, the other is what I would call structure. The difference is quite subtle, but I'll try to explain what I mean. Restriction is mainly something experienced by the programmer in the sense of "damn I can't do this". To get back to the start of this thread, keywords are among these because you can't use them as variable or method names. At least not conveniently, because you can do it through define_method and send. Structure is something that we search for when trying to understand programs, and that compilers search for when analyzing a program. Structure also guides us when we build our programs. Clearly, restrictions are bad, structure is good. Structure can seem like a restriction, with the classic example being goto. Structured programming forbids the use of goto, and that's generally regarded as a Good Thing, but not being able to goto is a restriction, especially if you're used to using goto. Maybe structure consists of the good restrictions only, so to be clear when I speak of restrictions they are only the bad ones. I think Charles is really asking for more structure and not for more restrictions. Take eval for example. Currently it is a method, but that fact by itself does not gain you much. Yes, you can potentially do things like alias it, but it's semantics is so different from other methods that this is potentially dangerous and mostly useless except maybe to move it out of the way because it is a method (and we're back where we started from,) and it can create hard to understand code. Making it a keyword is a restriction, so that's not ideal. A %e construct would be another possibility that offers more structure and no "real" restriction. Actually, eval as it is now is quite unstructured, and not just because it is a method. It's been only recently that several people on ruby-talk said they avoid eval. Eval can make code harder to read, and it can even make it dangerous unless when needed, you check what you interpolate, but that makes code even harder to read. This really has something to do with the fact that you want to pass it code, but you really pass it a string. Code is structured (or at least that's the hope), a string isn't (it's a sequence of characters.) This mismatch makes eval really hard to analyze. At this point I pose the hypothesis that Self has fewer restrictions than Ruby, but has more structure, and that's why Self can be optimized much better than Ruby. I don't know Self very well, but my experience tells me that this hypothesis must be true because it is structure that a compiler exploits. A compiler invariably hates random behavior (and this includes random as we perceive it, like a random number generator or better yet, certain of Wolfram's cellular automata.) Structure needs to be considered carefully because it can be quite fragile. Exposing internal run time structures, when done skilfully, removes restrictions without destroying structure. So I agree with you; exposing internal structures can be a good thing. But I don't think that making eval manifest contradicts that. I hope this makes sense to you. It's more philosophical than anything else really, largely because restriction is a subjective turn (you don't care about something you can't do until you want to do it,) and because structure is something that is hard to quantify. It's just some feeling/thought that has been growing as I experience/learn more about all kinds of compiler techniques. Peter