Re: Proposal: runtime-modifying Kernel methods should be keywords

On 18/07/07, Ryan Davis <[e-mail]> 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