[E-Lang] down with 'define'

[Marc Stiegler]

> Ok, I have a concrete proposal to put on the table:
>
> Make E scopes truly order independent, in the way Joule's are.  If a
> defining occurrence of "foo" appears anywhere in the top level of a scope
> box (that is, in the scope box but not in a nested scope box), the any use
> of "foo" anywhere in that scope box (including nested scope boxes that
don't
> shadow "foo") corresponds to that defining occurrence.
>
> Of course, like Joule, E isn't in the bind you point out above that Java
> would be were it to make this decision.  If the variable is used before
its
> initialized its value is a promise for what it will be initialized to.
Once
> it's initialized, all these promises resolve to this initial value.
>
> This proposal makes me queasy, but it's simpler than what we've got, and I
> don't actually see anything wrong with it yet.

Can you really make it so that

class carMaker(radar) {
    radar requestCrashImminentAlert(car)
    def  car {
        to reactToCrashAlert {car dodge}
        to dodge() {...}
    }
}

works the same as

class carMaker(radar) {
    def  car {
        to reactToCrashAlert {car dodge}
        to dodge() {...}
    }
    radar requestCrashImminentAlert(car)
}

even if radar uses car as a key in a hashtable? Somehow definition order is
still important. I am not sure whether this proposal  makes E easier to
explain or harder to explain.

My first reaction on maintenance of E is also mixed. As it is, if I see an
object in use, I know I can find the definition looking upwards. Such
ordering is more important in E than in Java. E's extensive use of scoping
behavior means that the average size of a file will be significantly larger
than in Java. Though a sufficiently powerful browser can find the tokens for
you wherever they are, I suppose.

Could this be more a matter of taste than correctness? I am intrigued by how
uncomfortable this proposal makes me.  Not getting a syntax error if I use
an integer before defining it seems really bizarre, and I'd guess it will
still fail when it starts executing.

--marcs