[E-Lang] newbie syntax: picayune points from a prejudiced programmer

Mark S. Miller markm@caplet.com
Wed, 28 Feb 2001 18:28:17 -0800

At 05:46 PM Wednesday 2/28/01, zooko@zooko.com wrote:

>I've started reading "E in a Walnut".  Here are some notes, in which 
>I deliberately choose to point out tiny syntactic objections which 
>I would normally pass over.
>* Why both "define" and "def"?  Just make "def" to be the only option,
>  please.  I love the Python paradigm: there is exactly one way to do
>  each common thing.

Based on all the feedback, I'm considering getting rid of "define" and 
leaving only "def" as you, Tyler, and other suggest.

Anyone want to speak up to save "define"?  Speak now or forever...

Note: If I do this, the transition release will have a switch that allows 
"define" to still be accepted.  The release after that will not.

>* In fact, would it be possible to provide Python's automatic
>  declaration of variables with no keyword?  If we could write
>  answer := a
>  instead of
>  def answer := a
>  this would be big win in terms of interactive, scripting,
>  fast-writing style.

We actually did this at one point (and there's still some dead code in the 
implementation for supporting this I need to remove), but only at top level 
scope, and only in an interactive environment.  Since then I've come to 
believe that it's a bad idea, even in this restricted setting (see previous 
correspondence with Hal & Bill about the semantics of re-entering code).

Outside this restricted setting, it's a terrible idea.  To obtain the code 
inspection advantage of lexical scoping (see previous reply to Vijay), it 
must be possible to easily match up a use-occurrence of a variable name to 
the corresponding defining occurrence.

>* Can we assume that functions with no type annotation are ":any"
>  functions?  I hate typing the same thing over and over, and ":any" is
>  going to be the type for > 90% of the functions, especially in
>  scripting/first-prototype code.

Actually, much greater than 10% of the functions/methods you'll define have 
return type ":void", and possibly even a majority of them.  But as Steve 
points out, this isn't the real issue.  The real issue is POLA -- the 
Principle Of Least Authority. If we made the default ":any", as we used to, 
then the path of least resistance would be to return the last value 
evaluated whether you needed to or not.  When you didn't need to, your own 
cooperative code would not use the extra authority accidentally provided it, 
and you wouldn't catch the security-hole bug in your code.  We actually had 
many such uncaught security holes before we made this change.

See the threads rooted at http://www.eros-os.org/~majordomo/e-lang/0844.html 
, http://www.eros-os.org/~majordomo/e-lang/0895.html , and 
http://www.eros-os.org/~majordomo/e-lang/0969.html .

>* [...] This
>  contrasts with parameterless methods for objects described later,
>  which do not require empty parentheses either during definition or
>  when called."
>  Ugh.  I wish that functions and methods looked identical except for
>  the presence of the object, and I wish that `()' were required on the
>  end of every single invokation, so that I can scan a page of text and
>  see the `(.*)' patterns and know where the invokations are.
>  Perhaps more importantly, the widely used syntaxes (C, Java, Perl,
>  and Python-if-you-count-Python), all require `()' at the end of every
>  invokation.

This is needed to make command line usage pleasant.  The shell languages 
people are used to don't require parens, dots, semicolons, or hardly any 
punctuation at all on simple invocations.  If they did, people would use 
different languages as shells. One of my goals, which I perhaps should have 
made more explicit, is to use one language as a shell, a lightweight 
"programming in the small" scripting language, and a serious "programming in 
the large" language. If this goal creates too great a conflict with the 
others, I would drop it. But I don't consider the issues raised here serious 
enough to give up on this "broad spectrum" goal.