[E-Lang] Syntax Reductions: Consensus so far

[Mark S. Miller]

At 01:54 AM Tuesday 3/6/01, Tyler Close wrote:
>I understand that there is a difference between the variable
>definition and the method name, but I am not sure that everyone needs
>to understand this. What sort of bad things could happen if people did
>not realize the distinction.
>
>Keep in mind that def foo() {} is now a final variable declaration, so
>we're not creating an assignable variable. The variable name and the
>method name are permanently bound.

One of the points of having an easy to learn surface level of the language, 
and a gentle introductory book, is, of course, to get people going quickly.  
Either of these proposals do that fine for their first week.

Another point relates to what someone (perhaps Ted Nelson or Alan Kay?) 
calls "self revealing systems".  Once someone is going, the system itself 
should suggest the deeper views, and should gently, incrementally, guide the 
user/programmer towards this deeper level of knowledge.  Even though E was 
in a much worse state at the time, a great example is the way MarcS 
kept a class-based model in his head for the first 6 months, and then, 
*despite his protestation* that he wasn't interesting in learning lambda 
calculus, he fully absorbed, and then made full and impressive use of the 
lambda-nature of E.  E itself taught him the lambda calculus -- I didn't.  

(Though I suspect these protestations were largely humorous, but he never 
let on, so only he knows for sure.  MarcS, are you ready to fess up?)

E currently says "def" for defining both objects and functions, but "to" for 
defining methods.  This is exactly right for teaching the next steps in 
learning E:  That both objects and functions are thing-like.  Both are first 
class, both can be held in variables, and both can be passed around.  E 
methods are not first class.  They are not thing-like, they are instead part 
of the behavior of things.  They cannot be held in variables.  And they 
cannot be passed around.  And finally there's the name spaces issue I raised 
before.

The very motivation for your proposal is to make functions look more 
method-like.  If anything, they look too method-like already.  Even with the 
current syntax, remember when MarcS-the-novice tried to define two 
functions with the same name but different arity in the same scope?  He 
tried to do this because he expected functions to do arity overloading like 
methods do.  If we used "to" instead of "def" for functions, it would be 
doubly hard for people to learn that functions are objects, not methods.


        Cheers,
        --MarkM