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

[Tyler Close]

Markm wrote:
> Zooko wrote:
> >  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.

Fine, but I think the "dropping the ()" sugar could also be
implemented as command line completion inside of an interactive shell
session. Static code should be forced to include the () for exactly
the reasons that Zooko mentions. Maybe the text editor that the E
programmer uses to write this static code could also do expression
completion.

In addition to Zooko's arguments, I want to point out another. Given
the following function:

def hello() :any {
	"hello"
}

You can invoke this function by writing:

	def greeting := hello run()

or:

	def greeting := hello run

or:

	def greeting := hello()

but not:

	def gretting := hello

Sometimes, dropping the () has no effect. Sometimes, it has a major
effect. This is just too fine. Depending on your mental state at the
time, it seems possible to convince yourself that the last variation
is also an invocation of the hello function.

You want the distinction between "hello" and "hello()" to be a major
distinction that you can hang semantics on. By supporting the
"optional ()" sugar, you make the distinction less clear.

Getting rid of the "optional ()" sugar would also reduce the number of
possible ways to invoke a function from 3 to 2.

Tyler