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
--
http://mail.python.org/mailman/listinfo/python-list
