[E-Lang] newbie syntax: picayune points from a prejudiced
Mark S. Miller
Wed, 28 Feb 2001 18:28:17 -0800
At 05:46 PM Wednesday 2/28/01, firstname.lastname@example.org 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
>* [...] 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
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.