English-like Python

[Adelle Hartley]

Joe Strout wrote:
 > Aaron Brady wrote:
 >
 >> Where functions are first-class objects, a bare function object isn't
 >> distinguishable either from its call.
 >
 > That depends not on whether functions are first-class objects, but on
 > the *syntax* of function invocation vs. function reference.  It just so
 > happens than in Python, the syntax for the latter is the bare function
 > identifier.  But it wouldn't have to be -- you could use "@foo" or
 > "{foo}" or "ref foo" or (as in RB) "AddressOf foo" or any number of
 > other alternatives to accomplish the same thing, and functions would
 > still be first-class objects.
 >
 > I'll grant that having any such syntax makes them *odd* first-class
 > objects, since all other objects are referred to with a naked
 > identifier, and invoked (if they are callable) with some other syntax.
 > It'd be weird and inconsistent to have functions turn that around.  But,
 > despite being inconsistent, it might still be sensible, based on the
 > observation that we generally need to invoke methods a lot more often
 > than we need to get a reference to them.

I propose the following syntax for invoking foo:

Computer, please foo that for me.

I know Jean Luc would just say "Computer, foo that" but I think that 
just because it's a computer doesn't mean we shouldn't be polite.

I have found English-like syntax to be useful in filtering sets.

Eg.

   parents = people.that.have.children

This looks nicer (at least to my eye) in languages that don't require 
parentheses everywhere, but that's entirely superficial.

One way that I've thought it might be possible to avoid the problem of 
ambiguity in identifying parameters is to not use them.

For example, instead of

   display(people.that.have.children)

why not

   display.people.that.have.children

or even

   display.a.list.of.people.that.have.children

I think this could only work within a confined domain, since "display" 
needs to know about all of the things that could be displayed.

Regarding ambiguities.  The way NL users resolve them is often to ask 
their interlocutor for clarification.  The problem for a program is that 
the programmer isn't around to answer questions when the answer is 
needed most - the problem of programming is in defining the desired 
behavior ahead of time.

If we are ever to use English as a programming language, I think the 
"compiler" would need to ask us clarifying questions at compile time and 
amend or annotate the source based on our answers.

The resulting source code may be a rarefied version of English or more 
like a "traditional" programming language, but our primary means of 
communicating with the computer could be more natural.

Back in the 90's I used to say things to my computer like

   Computer, please Label this command button "Parents".

I don't think it much of a stretch to have it respond to

   When the user clicks this button, bring up a list of all the people 
that have children.

by generating the code

   display.a.list.of.people.that.have.children

and to attach it to the right event.

But even that level of apparent naturalness belies a problem that other 
posters in this thread have already raised:  There are so many ways of 
saying the same thing, yet the computer will only ever understand a 
subset of them, making it harder to learn the "natural" system than any 
artificial programming language.

I had at one time defined a number of voice commands for designing a form:

   Place a <control> here.
   Place a <control> <to the left of|to the right of|above|below> <this 
control|<control name> >
   Move that <up|down|left|right> <number pixels|a bit|slightly>
   ...

Once I "got into it" I was pretty productive with it, but the experience 
is not unlike playing with text-based adventure games for the first time.

That is, you know what you want the program to do, but you either don't 
know how to say it in a way that the program will understand or you know 
the program well enough to know that there is no way of directly 
representing what you want to do within the program's narrow grasp of 
English.

I don't think the problem is fundamentally unsolvable, only that the 
scale of the problem is quite large, like writing a dictionary.

Adelle.