[E-Lang] down with 'define'

[Ralph Hartley]

Mark S. Miller wrote:

> At 03:04 AM Friday 3/2/01, Tyler Close wrote:
> 
>>> The other thing all these purifications of the language
>>> make me yearn for is
>>> the "declare" syntax.
>> 
>> 
>> I thought the "def name;" syntax won?
> 
> 
> 
> As MarcS also clarifies later, the issue is "declare <name>" as a 
> **forward** declaration of <name>, in order to bring <name> into scope 
> before it's defined, in order to make easier the writing of 
> recursively defined and mutually recursively defined objects.


Achhh! I **hate** forward declarations!

To be more precise, I hate languages where one might **need** forward 
declarations. That the legality, or meaning, of a program should depend 
on the order in which definitions appear is simply not palatable.

In any reasonable language, names have a scope. Often this is bounded by 
some sort of block (brackets etc.). It really should always be that way, 
it should not be bounded by the location of the definition.

It isn't that I use recursive, or mutually recursive, objects that often 
(though I suspect I do). It is that for any file longer than one editor 
page, it is not obvious where the piece I am working on is located 
relative to the definitions that it depends on. Having to worry about 
the **order** of definitions is just one more task, and it can be 
substantial. I have enough things to keep track of just remembering how 
my program is supposed to work.

Also, order dependence contradicts the basic semantics of definitions. A 
definition is a statement of fact, it should have at least some element 
of timelessness to it. The prototype for a definition is a dictionary 
entry. With good reason,  dictionaries are not laid out according to the 
dependencies between the words. Nor is a word used in earlier 
definitions in any way treated differently from the same word used after 
its own definition.

When I see order sensitive definitions, I think that I am just seeing 
assignments disguised as definitions, not **real** definitions.

I can see lots of reasons why E works the way it does. If you want to 
use it as a shell language, that use doesn't get along very well with 
"block structure". You want things to happen right away, not at the "}". 
There really is a reason for a separation between "shell" languages and 
those suitable for larger projects (not that shell languages haven't 
been used for large projects, it just involves pain). You know what 
happens when you try to please everyone.

> The awkwardness of the section where Walnut explains how to do 
> recursive definition in today's E ("Self-referencing objects" in 
> http://www.skyhunter.com/marcs/ewalnut.html#SEC12 ) makes clear that 
> we have a problem.


No joke.

Also, the only mechanism for using definitions in **different** files, 
that I found in Walnut (emakers), is rather heavyweight. Is that the 
only way?

Of course, I know that for E it is almost certainly way too late for the 
sort of basic redesign that would be needed to fix this properly. I 
guess I'll just have to wait for "F".

Ralph Hartley