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