English-like Python

[Joe Strout]

Steven D'Aprano wrote:

>>>     Foo
>>>
>>> Is that legal RB syntax?
>> You betcha!  
> 
> How do you know? I haven't specified what Foo does.

You haven't specified whether "Foo" is a valid identifier at all, so I'm 
assuming that it is both valid and used correctly here.  The syntax is 
certainly valid -- it matches the language grammar -- but whether the 
programmer was smoking something while typing it is another matter.

> You can't tell the difference between a syntax error and a valid call 
> without knowing what Foo does. In Python, you can always recognise a 
> syntax error without needing to worry about the semantics of the call. 
> This is not the case with RealBasic.

If "Foo" is undefined or not a subroutine with no required parameters, 
then it's not a syntax error; it's an undefined-identifier error, a 
you-must-use-the-result-of-this-function-call error, or a 
invalid-arguments error.  It is NOT a syntax error in any case.

This is no different in Python, where:

   Foo()

may be valid or not, depending on whether there actually exists a Foo 
method in an accessible scope that has no required parameters.  If so, 
it's valid Python code; if not, it is some sort of error.

The only difference is that RB will detect any of those errors at 
compile time, while Python will not detect them until this line of code 
is executed.

Given code that compiles/runs without error, the other difference 
between the two is that in RB, you can tell that Foo has no return 
value, whereas in Python you can't tell -- and if it does return a 
value, you can't tell whether the author of the line above is 
intentionally ignoring it, or was just ignorant.

>>      Beep
>>
>> Doesn't get much more readable and syntax-free than that.
> 
> readable doesn't mean smallest amount of syntax possible sometimes syntax 
> increases the readability of a text as you would see if we for example 
> dropped all punctuation but you probably already knew that but perhaps 
> you didnt draw the connection with programming language wink

Cute.  But I stand by my contention that "Beep" is about the most 
readable way imaginable to express the "make a beep sound now please" 
command, and any additional punctuation (parentheses, semicolons, etc.) 
only get in the way.

>> Suppose now
>> that a beep isn't eloquent enough, and you want the computer to speak
>> something out loud instead.  Also easy:
> 
> I've programmed in Hypertalk, which is full of constructs like:
> 
> get the value of field "Bar"
> put it into x
> put x+37 into x
> ask "Eat " & x " pies?" with "Yes please", "No thanks"
> if it is "Yes please" then go to card "PieCard"

Yes, AppleScript is like this to.  Beastly.  I consider those to be 
read-only languages -- easy to read, maddeningly difficult to write, as 
you often have to guess exactly which English-like construct is going to 
actually work.

> so I understand the principle of leaving out parentheses to make things 
> look kinda-sorta vaguely English-like.

That wasn't really my point here.  REALbasic isn't much more 
English-like than any other language; it's just much lighter on all the 
extra punctuation that seems to plague many other languages.  One Yuma 
(which uses the same language as RB) user put it this way:

"I'm so freaking excited about Yuma that I can barely write about it. 
It's an HTML preprocessor like PHP, but with clean syntax. This is good 
because PHP is nasty. It's powerful and ubiquitous, but it looks like 
someone with a mouthful of punctuation sneezed all over my screen."

The same comment would apply to any other C-derived language, such as 
ActionScript, Java[Script], C++, Obj-C, and so on.  Python is better 
than these, but still not as clean as Python.

>> But of course.  Any method call is legal only if the form of the call
>> matches the method prototype -- if you try to call a function that
>> requires 4 parameters, and give it only 3, that's an error too.  I don't
>> see how this is different in any important way.
> 
> But it isn't (presumably) a syntax error.

Right, thanks for confirming my point above.  :)

> I accept that in practice, it isn't a big deal once you get used to the 
> convention. But it's a special case -- why treat functions of zero 
> arguments as a special case just to save two characters?

It's not a special case.  It's an example of the general case, "only 
require parentheses where necessary to avoid ambiguity".  Pretty much 
all modern languages (i.e. please don't drag out LISP again) apply this 
principle in expressions, where "2+(3*5)" is the same as "2+3*5" -- 
parentheses here are optional because operator precedence already groups 
the terms unambiguously.

This is the same thing: if you want to multiply 10 by the result of a 
Rnd call and add 5, you can write "10*Rnd()+5" -- but the parentheses 
here aren't contributing anything.  They're not disambiguating anything 
or grouping anything or otherwise doing a job.  So you can instead write 
"10*Rnd+5" by the general principle above.

Similarly, if you have a subroutine call, then parentheses around its 
arguments don't really contribute anything -- the parser already knows 
that the list of zero or more comma-separated expressions following the 
identifier must be arguments.  So, again, the parens are optional.

> It seems to me that the cost of this is that using functions
 > as first-class objects takes a major usability hit.

That's true.  Use of functions in this way is much less common in RB. 
(And RB doesn't have any equivalent of lambda functions, so the code you 
wrote isn't easily translatable into RB.)  But I suggest that regular 
function calls are far more common than use of function references, even 
in Python.

Cheers,
- Joe