Re: English-like Python
On Feb 3, 2:01 pm, "J. Cliff Dyer" wrote: > On Tue, 2009-02-03 at 08:33 -0700, Joe Strout wrote: > > J. Cliff Dyer wrote: > > > > But what if your language allows functions to be used as first class > > > objects? (Mine does :)) > > > > x = Beep > > > > Does that assign the name x to the Beep object or does it assign the > > > result of a Beep call to x? > > > It assigns the result. To assign the name to the Beep object requires a > > bit of additional syntax; in RB, this would be > > > x = AddressOf Beep > > > > There's no virtue in making ridiculously simple things even simpler if > > > it makes the interesting things impossible. > > > Of course. The goal is (or should be) to make the common things > > ridiculously simple, and make the uncommon things only somewhat less so. > > Even in Python, it is far more common to invoke a function than to > > need a reference to it. So invoking a function should be the thing that > > requires no extra syntax (even including "()"). Getting a reference to > > it, which is less common, should be the thing that requires more syntax. > > Except that now you have introduced an inconsistency into python. What > does the following mean? > > my_object = MyObject() > x = my_object > > What if MyObject defines a method named __call__? > > Now some objects are passed around using > > x = my_object > > while others require > > x = AddressOf my_object > > and the only way to tell which is which is to check the object for the > presence of a __call__ method. > > This seems like a serious inconsistency to me. > > > Cheers, > > - Joe > > Cliff Well, just return to the natural language we're trying to model. x= going to the store x= go to the store Imperatives don't usually return values. x= the process of going to the store x= the result of going to the store I'm starting to think that PLs and NLs are quite dissimilar. What do return values are denoting phrases: x= the man in the corner x= the man in the corner talking to the woman Once you've established the subject, you usually make declarations about him/er/it. was_at_the_mall_today( x ) talked_to_me_earlier( x ) Usually you expect your audience to have reasoning capacities, and giving them declarative knowledge is preemptive to the need to give them orders later on. Ideally, interactions could take place entirely in the declarative: introduce yourself and wait-style. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
J. Cliff Dyer wrote: > On Tue, 2009-02-03 at 08:33 -0700, Joe Strout wrote: >> J. Cliff Dyer wrote: >> >>> But what if your language allows functions to be used as first class >>> objects? (Mine does :)) >>> >>> x = Beep >>> >>> Does that assign the name x to the Beep object or does it assign the >>> result of a Beep call to x? >> It assigns the result. To assign the name to the Beep object requires a >> bit of additional syntax; in RB, this would be >> >> x = AddressOf Beep >> >>> There's no virtue in making ridiculously simple things even simpler if >>> it makes the interesting things impossible. >> Of course. The goal is (or should be) to make the common things >> ridiculously simple, and make the uncommon things only somewhat less so. >> Even in Python, it is far more common to invoke a function than to >> need a reference to it. So invoking a function should be the thing that >> requires no extra syntax (even including "()"). Getting a reference to >> it, which is less common, should be the thing that requires more syntax. >> > > Except that now you have introduced an inconsistency into python. What > does the following mean? > > my_object = MyObject() > x = my_object > > What if MyObject defines a method named __call__? > > Now some objects are passed around using > > x = my_object > > while others require > > x = AddressOf my_object > > and the only way to tell which is which is to check the object for the > presence of a __call__ method. > > This seems like a serious inconsistency to me. > Time for my annual comment on the apparent requirement for DWIM-mode Python. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Tue, 2009-02-03 at 08:33 -0700, Joe Strout wrote: > J. Cliff Dyer wrote: > > > But what if your language allows functions to be used as first class > > objects? (Mine does :)) > > > > x = Beep > > > > Does that assign the name x to the Beep object or does it assign the > > result of a Beep call to x? > > It assigns the result. To assign the name to the Beep object requires a > bit of additional syntax; in RB, this would be > > x = AddressOf Beep > > > There's no virtue in making ridiculously simple things even simpler if > > it makes the interesting things impossible. > > Of course. The goal is (or should be) to make the common things > ridiculously simple, and make the uncommon things only somewhat less so. > Even in Python, it is far more common to invoke a function than to > need a reference to it. So invoking a function should be the thing that > requires no extra syntax (even including "()"). Getting a reference to > it, which is less common, should be the thing that requires more syntax. > Except that now you have introduced an inconsistency into python. What does the following mean? my_object = MyObject() x = my_object What if MyObject defines a method named __call__? Now some objects are passed around using x = my_object while others require x = AddressOf my_object and the only way to tell which is which is to check the object for the presence of a __call__ method. This seems like a serious inconsistency to me. > Cheers, > - Joe > Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Thu, 2009-01-22 at 09:07 -0700, Joe Strout wrote: > >> 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. > But what if your language allows functions to be used as first class objects? (Mine does :)) x = Beep Does that assign the name x to the Beep object or does it assign the result of a Beep call to x? There's no virtue in making ridiculously simple things even simpler if it makes the interesting things impossible. def tone_sequence(sound): sequence = DialTone.followed_by(sound) sequence() for x in Beep, Buzz, Warble: tone_sequence(x) Cheers, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
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 here.
Place a control| >
Move that
...
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
Re: English-like Python
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
Re: English-like Python
On Jan 22, 2:17 am, Steven D'Aprano wrote: > On Wed, 21 Jan 2009 08:17:34 -0700, Joe Strout wrote: > > 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. It often is a compile-time error, as opposed to run-time. However, if Joe meant to distinguish between 'Give the ball to Jamie' and 'Give the ball', it is a syntax error: 'Give( the ball, Jamie )' vs. 'Give ( the ball )'. (Wait, is 'give the ball' a syntax error or what?) > 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? In fact, NLs clearly mark the difference between commanding a process, and nominating it. 'Go to the store' is the imperative, while 'Going to the store' is the nominative. In this case, 'ing' serves to mark the absence of parentheses, and the bare form, without 'ing', marks the call. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 22, 1:46 am, Steven D'Aprano
wrote:
> On Wed, 21 Jan 2009 00:57:49 -0800, Aaron Brady wrote:
> > Natural language doesn't have the equivalent of parentheses,
>
> I take it you mean natural language doesn't have the equivalent of
> parentheses for *calling*, since NLs can (and do) use parentheses for
> grouping -- as well as various conventions regarding dashes -- terms
> together.
I take it back. I meant spoken languages.
> I'm not aware of any NL that uses some sort of calling convention, but it
> isn't impossible. Most sentences have an object, a subject and a verb,
> just like OO method calls. So logically:
>
> "Peter ate the sandwich"
>
> is equivalent to:
>
> Peter.eat(sandwich)
>
> modulo complications due to tenses and similar.
I don't think it's as common as you imply to give a sequence of
instructions in spoken language. It's more often rule-based, such as
'when X, Y' (the German for 'if' is 'wenn'), and 'Employees will X',
as well as 'X was wearing', and 'X is doing'. 'John is dating Mary'
is informational, whereas 'John.date( Mary )' is a step in a
procedure. How-to knowledge is often (I guess predominantly) tacit,
relying on agents to determine a missing step in a process, or fill in
from context. In fact, knowledge-based might be a better description
of most NL aims (many times with implied ordering). That is, mostly,
I want to alter your beliefs (OT: too often to create fear), not your
know-how specifically. When you do see imperatives, they're just
function calls, not walkthroughs. Programming is more resemblant to
math structure building. You'll notice that a PL translation of a
narrative don't look anything like code ('Banquo.take( dagger )'), and
declarative knowledge is best (I advance) expressed in a relational
language, like SQL. Further, when you have to be precise, PLs
(programming languages) are the language to do it in.
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Wed, 21 Jan 2009 08:17:34 -0700, Joe Strout wrote: > Steven D'Aprano wrote: ... >> But even if RB doesn't have these things, I question that the syntax is >> "beautiful". Consider some arbitrary method Foo. If you see this: >> >> Foo >> >> Is that legal RB syntax? > > You betcha! How do you know? I haven't specified what Foo does. As you say a little later on: >> Maybe yes, maybe no. It all depends on what Foo does. If it returns no >> result, then it's legal. If it returns a result, it isn't. > > Right. In other words, you can tell just by looking at the call that it > doesn't return a result. This is often handy. 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. > For example, the built-in method to play the standard > system alert sound is: > > 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 > 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" so I understand the principle of leaving out parentheses to make things look kinda-sorta vaguely English-like. I actually do like Hypertalk, I think it is neat, but I can tell you that you get no respect from other programmers when you show them your code :) >> So the question of whether syntax is legal depends, not on the >> syntactic elements involved, but on the *semantics* of the method >> (whether or not it returns a result). > > 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. 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 seems to me that the cost of this is that using functions as first-class objects takes a major usability hit. How would you write the equivalent of this in RealBasic? def func(f, args): args = reversed(args) return f(*args) x = func( lambda a, b, c: a+b*c, [1, 2, 3] ) y = func( lambda: 7, [] ) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Wed, 21 Jan 2009 00:57:49 -0800, Aaron Brady wrote: > Natural language doesn't have the equivalent of parentheses, I take it you mean natural language doesn't have the equivalent of parentheses for *calling*, since NLs can (and do) use parentheses for grouping -- as well as various conventions regarding dashes -- terms together. I'm not aware of any NL that uses some sort of calling convention, but it isn't impossible. Most sentences have an object, a subject and a verb, just like OO method calls. So logically: "Peter ate the sandwich" is equivalent to: Peter.eat(sandwich) modulo complications due to tenses and similar. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 21, 2:50 pm, Scott David Daniels wrote:
> Benjamin J. Racine wrote:
> > I think it would be a good step if you could make some sensible
> > interpretation of a typical statement without its parentheses.
>
> > f "abc" 123
> > -->
> > f( "abc", 123 )
>
> > It would be just the thing in a couple of situations... though it does
> > conflict with raw-string literals as stated: r"abc"... which if you left
> > open, would be susceptible to a local definition of r!. Maybe you could
> > put it after, like numeric literals: 123L, "abc"r, which is not bad.
>
> Surely this would require that
> f( "abc", 123 )
> -->
> f(("abc", 123))
> Or would you require that tuple-formation is "special"?
Natural language does have tuples, and there is some ambiguity some of
the time.
Go to the store and get bread.
-->
goto( store ); get( bread )
or:
get( store, bread )
-->
( Go to the store ), ( Get bread )
or:
( Go to ( the store, get bread ) )
Now for the good examples. ;)
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 21, 9:24 am, 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. Good point. snip. I'm not sure what the NL equivalents of function invocation vs. function reference are, but somehow I don't think there would be a lot of confusion (not that there couldn't be). Here is a bad example. Think about computing that answer. Compute the answer, and think about the result. --> thinkabout( func ) thinkabout( func() ) Oddly enough, the NL equivalents aren't even close to resembling each other. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Benjamin J. Racine wrote:
I think it would be a good step if you could make some sensible interpretation
of a typical statement without its parentheses.
f "abc" 123
-->
f( "abc", 123 )
It would be just the thing in a couple of situations... though it does conflict with raw-string
literals as stated: r"abc"... which if you left open, would be susceptible to a local
definition of r!. Maybe you could put it after, like numeric literals: 123L, "abc"r,
which is not bad.
Surely this would require that
f( "abc", 123 )
-->
f(("abc", 123))
Or would you require that tuple-formation is "special"?
--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
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'm granting that it's useful
to return values a lot. For example:
a= f
could mean either, 'a= f' or 'a= f()'. Once again the return values
save the day.
I think I agree (if I follow you correctly). But then some other syntax
would be needed for when you really mean "a=f" (i.e., make 'a' refer to
the same function as 'f').
Best,
- Joe
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Steven D'Aprano wrote:
LogError "Walk has gotten too silly", CurrentTime
Here, LogError is a method call that takes two arguments, and
CurrentTime is a method call that takes none.
That seems ambiguous to me. As a non-RealBasic programmer, I can see at
least four meanings it could have. Translated into Python, they are:
LogError("Walk has gotten too silly", CurrentTime)
LogError("Walk has gotten too silly"), CurrentTime
LogError("Walk has gotten too silly", CurrentTime())
LogError("Walk has gotten too silly"), CurrentTime()
It's not ambiguous because RB doesn't have a tuple syntax that looks the
same as arguments to a function call. You also can't get a reference to
a method simply by naming it; naming it invokes it (when you want a
reference to it instead, you use the "AddressOf" keyword). So, the
first and third of your lines above mean the same thing, and are the
correct (and only possible) interpretation. The second and fourth are
also equivalent, but would require the parentheses around the LogError
parameter since in that case it is a function (i.e. returns a result).
As I said before, I'm not sure how you would apply this to Python, where
other syntax choices (tuples, function references, etc.) get in the way
of this idea. I'm merely pointing out that what Aaron asked for is
possible without ambiguity, and actually used in at least one real-world
language.
But even if RB doesn't have these things, I question that the syntax is
"beautiful". Consider some arbitrary method Foo. If you see this:
Foo
Is that legal RB syntax?
You betcha! For example, the built-in method to play the standard
system alert sound is:
Beep
Doesn't get much more readable and syntax-free than that. Suppose now
that a beep isn't eloquent enough, and you want the computer to speak
something out loud instead. Also easy:
Speak "Spam, spam, spam, baked beans and spam."
If you're writing a console app, then there's a built in "Print"
subroutine that puts a string to stdout. Its usage is:
Print "Spam, spam, spam, baked beans and spam."
Note that this syntax is exactly like Python's "print" syntax prior to
3.0, but in RB, it's not a special case -- it's just another method
call, and you can define your own methods that you invoke exactly the
same way.
Maybe yes, maybe no. It all depends on what Foo
does. If it returns no result, then it's legal. If it returns a result,
it isn't.
Right. In other words, you can tell just by looking at the call that it
doesn't return a result. This is often handy.
So the question of whether syntax is legal depends, not on the
syntactic elements involved, but on the *semantics* of the method
(whether or not it returns a result).
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.
Eliminating unnecessary parentheses does a lot to improve the
readability of the code IMHO.
But they're not unnecessary, at least not in Python, they're useful for
distinguishing between calling the function and the function itself.
Yes, quite true in Python. If there were some other way to distinguish
between those -- and if tuple syntax didn't look the same as method call
arguments -- THEN they would be unnecessary. But those would be very
substantial changes to Python syntax, and I'm not seriously proposing them.
Best,
- Joe
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 21, 2:36 am, Steven D'Aprano
wrote:
> On Tue, 20 Jan 2009 11:58:46 -0700, Joe Strout wrote:
> > Aaron Brady wrote:
>
> >> I think it would be a good step if you could make some sensible
> >> interpretation of a typical statement without its parentheses.
>
> >> f "abc" 123
> >> -->
> >> f( "abc", 123 )
>
> >> It would be just the thing in a couple of situations...
>
> > Such a language is possible -- take a look at REALbasic sometime. RB
> > certainly has its problems (mainly bugs), but the language syntax is
> > beautiful. To your point, parentheses are not required around any
> > method call that (1) has no return value, or (2) requires no parameters.
> > Example:
>
> > LogError "Walk has gotten too silly", CurrentTime
>
> > Here, LogError is a method call that takes two arguments, and
> > CurrentTime is a method call that takes none.
>
> That seems ambiguous to me. As a non-RealBasic programmer, I can see at
> least four meanings it could have. Translated into Python, they are:
>
> LogError("Walk has gotten too silly", CurrentTime)
> LogError("Walk has gotten too silly"), CurrentTime
> LogError("Walk has gotten too silly", CurrentTime())
> LogError("Walk has gotten too silly"), CurrentTime()
>
> Of course this assumes that RealBasic has an equivalent of tuples, and
> treats functions as first class objects.
>
> But even if RB doesn't have these things, I question that the syntax is
> "beautiful". Consider some arbitrary method Foo. If you see this:
>
> Foo
>
> Is that legal RB syntax? Maybe yes, maybe no. It all depends on what Foo
> does. If it returns no result, then it's legal. If it returns a result,
> it isn't. So the question of whether syntax is legal depends, not on the
> syntactic elements involved, but on the *semantics* of the method
> (whether or not it returns a result).
If you could deduce the semantics of a function from the syntax
always, you could follow Erik's observation about Logo. Then
expressions would have unique interpretations, except where a function
takes no arguments and functions are first class objects. In other
words,
g f "abc" 123
would have an exact meaning, since f would just get the innermost n
arguments, that since 'n' would be a known quantity. (Order of
precedence would handle 'g f "abc" + "123"'.)
> > Eliminating unnecessary parentheses does a lot to improve the
> > readability of the code IMHO.
>
> But they're not unnecessary, at least not in Python, they're useful for
> distinguishing between calling the function and the function itself.
Natural language doesn't have the equivalent of parentheses, which
goes back to Steven's point about a beautiful math structure vs. a
beautiful NL sentence. Did anyone have to diagram sentences in
grammar school? It's not like the essentials for communication
involve deeply nested sentences; you can get by with a few simple
declarations, so you and your company will reject anything "higher-
order".
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 20, 9:16 pm, MRAB wrote:
> Terry Reedy wrote:
> > Joe Strout wrote:
> >> Aaron Brady wrote:
>
> >>> I think it would be a good step if you could make some sensible
> >>> interpretation of a typical statement without its parentheses.
>
> >>> f "abc" 123
> >>> -->
> >>> f( "abc", 123 )
>
> > How would you differentiate
>
> > f 'abc' + 'def'
> > as
> > f('abc') + 'def'
> > versus
> > f('abc' + 'def')
>
> >> Such a language is possible -- take a look at REALbasic sometime. RB
> >> certainly has its problems (mainly bugs), but the language syntax is
> >> beautiful. To your point, parentheses are not required around any
> >> method call that (1) has no return value, or (2) requires no
> >> parameters. Example:
>
> >> LogError "Walk has gotten too silly", CurrentTime
>
> > LogError('walk', Time) # versus
> > LogError('walk'), Time
>
> > Perhaps RB does not have tuple literals.
>
> Parentheses wouldn't be required if it's a procedure call (I'm not sure
> about a function that's called as a procedure) or if there are no
> parameters to pass. Thus:
>
> f 'abc' + 'def'
>
> does:
>
> f('abc' + 'def')
Where functions are first-class objects, a bare function object isn't
distinguishable either from its call. I'm granting that it's useful
to return values a lot. For example:
a= f
could mean either, 'a= f' or 'a= f()'. Once again the return values
save the day.
In the case of Terry's example, it's covered by Joe's caveat that
functions can't return values without parentheses, since '+' is a
function. However, order of precedence could help.
Python and C of course allow string concatenation by adjacency, so
there's further ambiguity there. It might fall under Terry's case.
You can look at English to get started, and try to see how native
speakers resolve the ambiguities. It doesn't just happen with verbs,
either. Firstly, Python lacks the notion of determiners (denoting
phrases) per se. That is, there's no way to say 'the black dog'.
Here's an approximation though.
"The black dog and the cat walked to the store."
walked( ( dogs( color= black ), cat ), store )
Secondly, Python is entirely imperative, something I was alluding to
in another post, which was about a relation object. English declares
the event, while Python commands it:
( dog, cat ).walk( store )
It addresses the subjects, and gives them orders. On a tangent, I
think the 'join' method on threads is a little counter-intuitive,
since the entity you're giving the instruction to is actually the
caller, not the object. The verb is a little counter-intuitive,
though, since if I say 'Team, join us!', it actually just means, 'Us,
wait for the team'. It's not like 'join' causes the target to break
early or hustle or anything.
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Tue, 20 Jan 2009 11:58:46 -0700, Joe Strout wrote:
> Aaron Brady wrote:
>
>> I think it would be a good step if you could make some sensible
>> interpretation of a typical statement without its parentheses.
>>
>> f "abc" 123
>> -->
>> f( "abc", 123 )
>>
>> It would be just the thing in a couple of situations...
>
> Such a language is possible -- take a look at REALbasic sometime. RB
> certainly has its problems (mainly bugs), but the language syntax is
> beautiful. To your point, parentheses are not required around any
> method call that (1) has no return value, or (2) requires no parameters.
> Example:
>
> LogError "Walk has gotten too silly", CurrentTime
>
> Here, LogError is a method call that takes two arguments, and
> CurrentTime is a method call that takes none.
That seems ambiguous to me. As a non-RealBasic programmer, I can see at
least four meanings it could have. Translated into Python, they are:
LogError("Walk has gotten too silly", CurrentTime)
LogError("Walk has gotten too silly"), CurrentTime
LogError("Walk has gotten too silly", CurrentTime())
LogError("Walk has gotten too silly"), CurrentTime()
Of course this assumes that RealBasic has an equivalent of tuples, and
treats functions as first class objects.
But even if RB doesn't have these things, I question that the syntax is
"beautiful". Consider some arbitrary method Foo. If you see this:
Foo
Is that legal RB syntax? Maybe yes, maybe no. It all depends on what Foo
does. If it returns no result, then it's legal. If it returns a result,
it isn't. So the question of whether syntax is legal depends, not on the
syntactic elements involved, but on the *semantics* of the method
(whether or not it returns a result).
> Eliminating unnecessary parentheses does a lot to improve the
> readability of the code IMHO.
But they're not unnecessary, at least not in Python, they're useful for
distinguishing between calling the function and the function itself.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Terry Reedy wrote:
Joe Strout wrote:
Aaron Brady wrote:
I think it would be a good step if you could make some sensible
interpretation of a typical statement without its parentheses.
f "abc" 123
-->
f( "abc", 123 )
How would you differentiate
f 'abc' + 'def'
as
f('abc') + 'def'
versus
f('abc' + 'def')
Such a language is possible -- take a look at REALbasic sometime. RB
certainly has its problems (mainly bugs), but the language syntax is
beautiful. To your point, parentheses are not required around any
method call that (1) has no return value, or (2) requires no
parameters. Example:
LogError "Walk has gotten too silly", CurrentTime
LogError('walk', Time) # versus
LogError('walk'), Time
Perhaps RB does not have tuple literals.
Parentheses wouldn't be required if it's a procedure call (I'm not sure
about a function that's called as a procedure) or if there are no
parameters to pass. Thus:
f 'abc' + 'def'
does:
f('abc' + 'def')
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Joe Strout wrote:
Aaron Brady wrote:
I think it would be a good step if you could make some sensible
interpretation of a typical statement without its parentheses.
f "abc" 123
-->
f( "abc", 123 )
How would you differentiate
f 'abc' + 'def'
as
f('abc') + 'def'
versus
f('abc' + 'def')
Such a language is possible -- take a look at REALbasic sometime. RB
certainly has its problems (mainly bugs), but the language syntax is
beautiful. To your point, parentheses are not required around any
method call that (1) has no return value, or (2) requires no parameters.
Example:
LogError "Walk has gotten too silly", CurrentTime
LogError('walk', Time) # versus
LogError('walk'), Time
Perhaps RB does not have tuple literals.
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 16, 12:02 pm, The Music Guy wrote: > Just out of curiousity, have there been any attempts to make a version > of Python that looks like actual English text? I mean, so much of Python > is already based on the English language that it seems like the next > natural step would be to make a programming language which is actually a > spoken one. I'm reminded of Lingua::Romana::Perligata which was done in Perl rather than Python, with the far more noble aim of programming in a language no longer spoken. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Joe Strout wrote:
Aaron Brady wrote:
I think it would be a good step if you could make some sensible
interpretation of a typical statement without its parentheses.
f "abc" 123
-->
f( "abc", 123 )
It would be just the thing in a couple of situations...
Such a language is possible -- take a look at REALbasic sometime. RB
certainly has its problems (mainly bugs), but the language syntax is
beautiful. To your point, parentheses are not required around any
method call that (1) has no return value, or (2) requires no parameters.
Logo, of all things, doesn't require parentheses at all, since functions
("procedures") take a fixed number of arguments. Parentheses are only
required when you're adding optional arguments.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
Conversation is the enemy of good wine and food.
-- Alfred Hitchcock
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Joe Strout wrote:
Aaron Brady wrote:
Unambiguity and readability are two different things. (This should be
a quasi-tangent, neither agreed, nor opposed, nor unrelated to what
you said.)
If you have
f "abc" 123
it's unambiguous, but, if you have
g f "abc" 123 "def"
there's no sure way to determine where the call to 'f' stopped, and
the one to 'g' resumed (or, as in Python, if 'f' was even to be called
at all, as opposed to 4 parameters to 'g').
Right -- that's exactly why (in RB) parentheses are required around
arguments to a method call if that method returns a value (in RB terms,
if it is a function rather than a subroutine). Then there is no
ambiguity, because only such a function can be used as an argument to
another method call (or otherwise be part of an expression). The above
would have to be written something like:
g f("abc", 123), "def"
I'm not saying I know how to translate this into Python -- some of
Python's other language features make this difficult. Just pointing out
that your original wish is possible in at least some languages.
Next you'll be saying that print(x) in Python 3.x should become print x
in python 4.x! :-)
--
http://mail.python.org/mailman/listinfo/python-list
RE: English-like Python
Doesn't ipython (the interactive shell) make this possible in some cases... not that's what you seem to be looking for exactly. Ben Racine -Original Message- From: python-list-bounces+bjracine=glosten@python.org [mailto:python-list-bounces+bjracine=glosten@python.org] On Behalf Of Aaron Brady Sent: Tuesday, January 20, 2009 10:14 AM To: python-list@python.org Subject: Re: English-like Python On Jan 17, 6:10 pm, The Music Guy wrote: > Wow, impressive responses. > > It sounds like the general consensus is that English would not be a > good choice for programming even if there were an interpreter capable > of turning human language into machine language. But that makes sense; > even English professionals have trouble understanding each other sometimes. > Until that problem is somehow overcome, there's not much hope of > computers to overcome it. I think it would be a good step if you could make some sensible interpretation of a typical statement without its parentheses. f "abc" 123 --> f( "abc", 123 ) It would be just the thing in a couple of situations... though it does conflict with raw-string literals as stated: r"abc"... which if you left open, would be susceptible to a local definition of r!. Maybe you could put it after, like numeric literals: 123L, "abc"r, which is not bad. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Aaron Brady wrote:
Unambiguity and readability are two different things. (This should be
a quasi-tangent, neither agreed, nor opposed, nor unrelated to what
you said.)
If you have
f "abc" 123
it's unambiguous, but, if you have
g f "abc" 123 "def"
there's no sure way to determine where the call to 'f' stopped, and
the one to 'g' resumed (or, as in Python, if 'f' was even to be called
at all, as opposed to 4 parameters to 'g').
Right -- that's exactly why (in RB) parentheses are required around
arguments to a method call if that method returns a value (in RB terms,
if it is a function rather than a subroutine). Then there is no
ambiguity, because only such a function can be used as an argument to
another method call (or otherwise be part of an expression). The above
would have to be written something like:
g f("abc", 123), "def"
I'm not saying I know how to translate this into Python -- some of
Python's other language features make this difficult. Just pointing out
that your original wish is possible in at least some languages.
Best,
- Joe
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 20, 12:58 pm, Joe Strout wrote: > Aaron Brady wrote: > > I think it would be a good step if you could make some sensible > > interpretation of a typical statement without its parentheses. > > > f "abc" 123 > > --> > > f( "abc", 123 ) > > > It would be just the thing in a couple of situations... > > Such a language is possible -- take a look at REALbasic sometime. RB > certainly has its problems (mainly bugs), but the language syntax is > beautiful. To your point, parentheses are not required around any > method call that (1) has no return value, or (2) requires no parameters. > Example: > > LogError "Walk has gotten too silly", CurrentTime > > Here, LogError is a method call that takes two arguments, and > CurrentTime is a method call that takes none. > > Your "f" example above works fine in RB too, though with such an > abstract example it's a little hard to see why it's so cool. > > Eliminating unnecessary parentheses does a lot to improve the > readability of the code IMHO. > > Cheers, > - Joe Unambiguity and readability are two different things. (This should be a quasi-tangent, neither agreed, nor opposed, nor unrelated to what you said.) If you have f "abc" 123 it's unambiguous, but, if you have g f "abc" 123 "def" there's no sure way to determine where the call to 'f' stopped, and the one to 'g' resumed (or, as in Python, if 'f' was even to be called at all, as opposed to 4 parameters to 'g'). If you allow commas, you can make some progress, though I don't have a rigorous formula. But, for example, g f "abc", 123 "def" can only mean: g( f( "abc", 123 ), "def" ) But something tells me it doesn't extend, especially since commas are used elsewhere than function calls. And certainly, it's not readable at a glance. English has that problem and kind of glaringly, by the way. You don't always know how the speaker's subordinate clauses are nesting. Not just with clauses, but modifiers, as in "The Purple People Eater". So I don't know how you expect to design a programming language after it. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Python is English-like enough that everybody including non-programmers can
understand it.e.g
# Import the operating system module
import os
# define new function
def open_dir_tree(path):
for File in os.listdir(path):
file_or_dir = os.path.join(path, File)
# Read the line below, this is almost full english language
if os.path.isdir(file_or_dir) and not os.path.islink(file_or_dir):
open_dir_tree(file_or_dir)
else:
print file_or_dir
open_dir_tree(".")
--
I develop dynamic website with PHP & MySql, Let me know about your site
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Aaron Brady wrote: I think it would be a good step if you could make some sensible interpretation of a typical statement without its parentheses. f "abc" 123 --> f( "abc", 123 ) It would be just the thing in a couple of situations... Such a language is possible -- take a look at REALbasic sometime. RB certainly has its problems (mainly bugs), but the language syntax is beautiful. To your point, parentheses are not required around any method call that (1) has no return value, or (2) requires no parameters. Example: LogError "Walk has gotten too silly", CurrentTime Here, LogError is a method call that takes two arguments, and CurrentTime is a method call that takes none. Your "f" example above works fine in RB too, though with such an abstract example it's a little hard to see why it's so cool. Eliminating unnecessary parentheses does a lot to improve the readability of the code IMHO. Cheers, - Joe -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 17, 6:10 pm, The Music Guy wrote: > Wow, impressive responses. > > It sounds like the general consensus is that English would not be a good > choice for programming even if there were an interpreter capable of > turning human language into machine language. But that makes sense; even > English professionals have trouble understanding each other sometimes. > Until that problem is somehow overcome, there's not much hope of > computers to overcome it. I think it would be a good step if you could make some sensible interpretation of a typical statement without its parentheses. f "abc" 123 --> f( "abc", 123 ) It would be just the thing in a couple of situations... though it does conflict with raw-string literals as stated: r"abc"... which if you left open, would be susceptible to a local definition of r!. Maybe you could put it after, like numeric literals: 123L, "abc"r, which is not bad. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
The Music Guy wrote: Just out of curiousity, have there been any attempts to make a version of Python that looks like actual English text? Many have tried that in the decades, but IMHO the best approach is to just rename the language. We cannot do that since it's already been trademarked for that very reason. From Wikipedia: ENGLISH (actually trademarked in all caps) is a database retrieval and reporting language somewhat like SQL, but with no actual programming or update capabilities. Originally released by Microdata in 1973 and named so that the company's brochures could claim that developers could generate reports on their implementation of the Pick operating system using English. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Wow, impressive responses. It sounds like the general consensus is that English would not be a good choice for programming even if there were an interpreter capable of turning human language into machine language. But that makes sense; even English professionals have trouble understanding each other sometimes. Until that problem is somehow overcome, there's not much hope of computers to overcome it. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
2009/1/16 has : > http://www.alice.org/ Ooh, "JavaLikeSyntax.py" indeed! Why not "PythonLikeSyntax", since that's apparently what they used! -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
2009/1/17 Kay Schluehr : > On 16 Jan., 02:02, The Music Guy wrote: >> Just out of curiousity, have there been any attempts to make a version >> of Python that looks like actual English text? > > No, but I've once written a Python dialect that uses German text. Just > look at how amazing this result is !!! But be warned it requires > knowledge of the German language. > > http://www.fiber-space.de/EasyExtend/doc/teuton/teuton.htm > You might find HPL (Hebrew Programming Language) interesting: http://hpl.sourceforge.net/ HPL is PHP but with Hebrew operators, commands, and builtin functions. The interesting thing is that HPL is actually useful, as Hebrew and Arabic are written from right to left and many text editors get confused with RTL and LTR text on the same line. So typing in HPL looks better in the text editor and is more easily understood. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я ä-ö-ü-ß-Ä-Ö-Ü -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On 16 Jan., 02:02, The Music Guy wrote:
> Just out of curiousity, have there been any attempts to make a version
> of Python that looks like actual English text?
No, but I've once written a Python dialect that uses German text. Just
look at how amazing this result is !!! But be warned it requires
knowledge of the German language.
http://www.fiber-space.de/EasyExtend/doc/teuton/teuton.htm
> I mean, so much of Python
> is already based on the English language that it seems like the next
> natural step would be to make a programming language which is actually a
> spoken one.
As you know Python 3.0 has full unicode support. Python 4.0 will be
surely written in Mandarin or Hindi.
> For example, the following code...
>
> >>> import os
>
> >>> def list_files(dirname):
> >>> for p in os.listdir(dirname):
> >>> print p
>
> >>> list_files("some_dir")
>
> foo
> bar
> etc
>
> ...might be translated as...
>
> >>> Import the operating system module.
>
> >>> Define a new function as "list files" which accepts
>
> "a path" and does the following:
> For every item in the list returned by the operating system's
> directory listing of the given path, do the following:
> Print the item.
>
> >>> List files from "some_dir".
>
> foo
> bar
> etc
>
> Obviously, creating a parser capable of handling such "code" would
> require a very good understanding not only of the English language but
> also of how ideas expressed in spoken languages are represented in terms
> that a computer can understand.
Yep. Resolving ambiguities in natural languages is actually an open
research topic. Moving from Python to a language that is more context
dependent than Larry Wall ever dreamed about and launch an interpreter
on the Enterprise is actually a worthwhile project for future
generations.
Kay
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 15, 7:02 pm, The Music Guy wrote:
> Just out of curiousity, have there been any attempts to make a version
> of Python that looks like actual English text? I mean, so much of Python
> is already based on the English language that it seems like the next
> natural step would be to make a programming language which is actually a
> spoken one.
>
> For example, the following code...
>
> >>> import os
>
> >>> def list_files(dirname):
> >>> for p in os.listdir(dirname):
> >>> print p
>
> >>> list_files("some_dir")
>
> foo
> bar
> etc
>
> ...might be translated as...
>
> >>> Import the operating system module.
>
> >>> Define a new function as "list files" which accepts
>
> "a path" and does the following:
> For every item in the list returned by the operating system's
> directory listing of the given path, do the following:
> Print the item.
>
> >>> List files from "some_dir".
>
> foo
> bar
> etc
>
> Obviously, creating a parser capable of handling such "code" would
> require a very good understanding not only of the English language but
> also of how ideas expressed in spoken languages are represented in terms
> that a computer can understand.
>
> A language like this would, of course, blow a lot of staple coding
> coding concepts like "variables," "objects," etc. right out of the
> water. I think, however, that it could be done, and wouldn't necessarily
> have to be any slower than any other scripting language as any text/code
> could be cached as bytecode, just like Python.
>
> I know it's sort of silly but I think something like this would be very
> interesting, maybe even useful. ^_^
I'm actually moderately interested in this idea. I was pursuing it a
while back, but didn't find anyone else interested. You want to avoid
requiring an understanding, since English syntax doesn't always
guarantee its semantics. Even a trivial transformation from non-
delimited English can cause an AmbiguityException.
The basics started like this:
'a= open "file1.py"' --> 'a= open( "file1.py" )'
'''
a= nat_list()
append 0 to a
append 1 to a
sort a
'''
-->
'''
a= nat_list()
a.append( 0 )
a.append( 1 )
a.sort()
'''
However, as you can see, 'open a' can map to both 'a.open()' and 'open
( a )'. If 'open' is both a method on 'a', and a callable defined in
current scope, the expression is ambiguous and raises an
AmbiguityException.
If you're willing to constrain yourself to a subset of English which
the language will understand, you open a lot of doors; that is, if you
will accept a 'more natural Python' instead of 'true natural Python'.
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
alex23 wrote: On Jan 16, 5:39 pm, Erik Max Francis wrote: Inform 7 has some interesting ideas, but I think the general problem with English-like programming language systems is that once you get into the nitty gritty details, you end up having to know exactly the right things to type, This has always been my impression of Inform 7. I have a lot of respect for what they've set out to achieve but English isn't exactly known for its lack of ambiguity. This is great for literature but not so helpful for programming. which ultimately get just as complicated as a more traditional programming language syntax. And much more verbose, as well. Agreed. I, too, am impressed with what the authors tried to do for Inform 7. -- Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis Laws are silent in time of war. -- Cicero -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On 16 Jan, 05:42, Chris Rebert wrote: > On Thu, Jan 15, 2009 at 5:02 PM, The Music Guy wrote: > > > > > Just out of curiousity, have there been any attempts to make a version > > of Python that looks like actual English text? > > [...] > Does the name "AppleScript" mean anything to you? ;-) [quoting myself on the subject] The big advantage of AppleScript syntax is that it makes it easy to get a broad idea of what an existing AppleScript does, even if you don't know the AppleScript language in particular or programming in general. The big disadvantage of AppleScript syntax is that it makes it very difficult to form an accurate understanding of how it actually does it. For example, is 'foo bar' a property name, a constant name, a command name, a command name followed by a property/constant/variable name, or something else again? With more conventional language syntaxes, you have the opposite situation: in order to make any sense at all of an existing script, you first have to learn to read the syntax and know some basic programming. OTOH, once you're past that initial hurdle, it's easier to understand exactly what makes it tick, e.g. x.foo_bar is a property name, :foo_bar is a constant, foo_bar() is a command, foo(bar) is a command name followed by a variable name, and so on. The upshot of this is that AppleScript has a lower barrier to entry but higher cost of use compared to other languages. It's a trade-off, but one that probably fits quite well with the needs of many AppleScripters, who write relatively small programs on an irregular basis. A high cost of entry will be harder to justify if you don't actually use the language very often. OTOH, if you write large programs on a daily basis then what matters most is long-term productivity, and you'll recoup the time taken to learn a language fairly quickly by comparison. ... If you really want an end-user language that has the legibility of already-familiar natural languages while retaining all the precision provided by traditional programming syntax and adding a lot of much- needed interactive help and guidance, I think the best approach would be to go with an 'intelligent' structure editor a-la Scratch or Alice, rather than 'dumb' character-based source code as found in Python, AppleScript, Inform-7, C, et-al. See: http://scratch.mit.edu/ http://www.alice.org/ If you eliminate the need for syntax to describe structure, you can present programs in whatever way suits users best - be it English words in coloured blocks, or traditional brackets and braces. Plus it becomes an awful lot easier to help and correct novice users as they put together their first programs - much as the original Mac GUI provided much better input guidance and error prevention over previous DOS-style command lines. HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
2009/1/16 The Music Guy : > Just out of curiousity, have there been any attempts to make a version > of Python that looks like actual English text? I mean, so much of Python > is already based on the English language that it seems like the next > natural step would be to make a programming language which is actually a > spoken one. > This one is close: http://en.wikipedia.org/wiki/Brainfuck -- Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я ä-ö-ü-ß-Ä-Ö-Ü -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 16, 8:39 am, Erik Max Francis wrote: > I was thinking of this as well when I saw his post. Inform 7 has some > interesting ideas, but I think the general problem with English-like > programming language systems is that once you get into the nitty gritty > details, you end up having to know exactly the right things to type, > which ultimately get just as complicated as a more traditional > programming language syntax. In the big picture I don't think it helps > much. After all, there's a reason that most modern programming > languages don't look like COBOL or AppleScript. COBOL looks like English to facilitate reading programs, not writing them. COBOL is for use in places where programs must be read and verified by possibly computer-illiterate personnel. E.g. in bank and finance where (at least in some countries) everything must be supervised and approved by professional accountants. COBOL is still the dominating language in that domain. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
[Hit Reply instead of Reply All. Sorry alex23.] alex23 wrote: On Jan 16, 5:39 pm, Erik Max Francis wrote: Inform 7 has some interesting ideas, but I think the general problem with English-like programming language systems is that once you get into the nitty gritty details, you end up having to know exactly the right things to type, This has always been my impression of Inform 7. I have a lot of respect for what they've set out to achieve but English isn't exactly known for its lack of ambiguity. This is great for literature but not so helpful for programming. which ultimately get just as complicated as a more traditional programming language syntax. And much more verbose, as well. I once had to do something in AppleScript. The problem I found was that it tried so much to resemble English that it wasn't always clear what was valid! Programming languages need to look artificial to remind you that the computers aren't intelligent. Python, for example, is clearly artificial but with a clear syntax and short (but not too short) reserved words. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 16, 3:15 am, alex23 wrote: > On Jan 16, 5:39 pm, Erik Max Francis wrote: > > > Inform 7 has some > > interesting ideas, but I think the general problem with English-like > > programming language systems is that once you get into the nitty gritty > > details, you end up having to know exactly the right things to type, > > This has always been my impression of Inform 7. I have a lot of > respect for what they've set out to achieve but English isn't exactly > known for its lack of ambiguity. This is great for literature but not > so helpful for programming. > > > which ultimately get just as complicated as a more traditional > > programming language syntax. > > And much more verbose, as well. Since I've used Inform 7 I can say that the syntactic problem isn't that great: once you get far enough into a project to matter the specialized constraints just sink in. It's more work to learn, but no stranger than Python's indentation scheme. The bigger problem for the comparison is that Inform 7 is a Domain Specific Language (DSL), not a general purpose language. Not only that, but the domain is pretty much everyday experience (with a large dollop of fantasy, of course). All the feedback is that the results are quite readable to non-programmers. This is why well over half of the mailing list posts on the authoring mailing list are about Inform 7. I really don't think that using natural language for a general purpose programming language is a good idea, for reasons that several other people have already said. I think it's a great idea for DSLs, at least in some cases. The other really major problem is that I don't think anyone really knows how to process natural language. The direction that natural language processing has taken in the last 50 years has come up lacking big-time. It does a good job in a single domain, but try to build something that crosses domains and nothing works. There isn't a good alternative in sight John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Jan 16, 5:39 pm, Erik Max Francis wrote: > Inform 7 has some > interesting ideas, but I think the general problem with English-like > programming language systems is that once you get into the nitty gritty > details, you end up having to know exactly the right things to type, This has always been my impression of Inform 7. I have a lot of respect for what they've set out to achieve but English isn't exactly known for its lack of ambiguity. This is great for literature but not so helpful for programming. > which ultimately get just as complicated as a more traditional > programming language syntax. And much more verbose, as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
The Music Guy wrote:
Just out of curiousity, have there been any attempts to make a version
of Python that looks like actual English text? I mean, so much of Python
is already based on the English language that it seems like the next
natural step would be to make a programming language which is actually a
spoken one.
For example, the following code...
import os
def list_files(dirname):
for p in os.listdir(dirname):
print p
list_files("some_dir")
foo
bar
etc
...might be translated as...
Import the operating system module.
Define a new function as "list files" which accepts
"a path" and does the following:
For every item in the list returned by the operating system's
directory listing of the given path, do the following:
Print the item.
List files from "some_dir".
foo
bar
etc
Obviously, creating a parser capable of handling such "code" would
require a very good understanding not only of the English language but
also of how ideas expressed in spoken languages are represented in terms
that a computer can understand.
A language like this would, of course, blow a lot of staple coding
coding concepts like "variables," "objects," etc. right out of the
water. I think, however, that it could be done, and wouldn't necessarily
have to be any slower than any other scripting language as any text/code
could be cached as bytecode, just like Python.
I know it's sort of silly but I think something like this would be very
interesting, maybe even useful. ^_^.
Others have mentioned some examples in this direction. Some problems:
English is not a context free language; a constrained context-free
subset is needed for algorithmic parsing. Should Pynglish change 'a' to
'an' before vowels?
'Define new function "list files"' is good English too. In your
example, you changed '"a path"' to 'the given path'. This will not
parse very easily. Etc.
Writing within such a subset is likely to be more difficult than writing
in Python. It would be easier to slip up and less easy to notice an
error. (Of course, some think Python is too wordy. I think is strikes a
fair balance.) It would also soon get tedious.
It would also be more tedious to read. There is a reason math shifted
from 'plain Greek' to the use of symbols.
While Python uses names derived from English, it is used
internationally. Pynglish would be harder for non-native-English
speakers to learn. I think random indentifiers in non-Latin alphabets
would be more grating in Pynglish sentences than in Python statements.
def #&*#&*$(#%,#^): # versus
Define a new function #&*#&*$ which accepts #% and #^
One could disagree though.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
Tobias Andersson wrote: The Music Guy skrev: Just out of curiousity, have there been any attempts to make a version of Python that looks like actual English text? I mean, so much of Python is already based on the English language that it seems like the next natural step would be to make a programming language which is actually a spoken one. Take a look at Inform 7. It's not Python but does something similar to what you are describing: www.inform-fiction.org Check out the examples in the tutorial. Some of them are quite elegant. I was thinking of this as well when I saw his post. Inform 7 has some interesting ideas, but I think the general problem with English-like programming language systems is that once you get into the nitty gritty details, you end up having to know exactly the right things to type, which ultimately get just as complicated as a more traditional programming language syntax. In the big picture I don't think it helps much. After all, there's a reason that most modern programming languages don't look like COBOL or AppleScript. -- Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis Physics, as we know it, will be over in six months. -- Max Born, 1928 -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
The Music Guy skrev: Just out of curiousity, have there been any attempts to make a version of Python that looks like actual English text? I mean, so much of Python is already based on the English language that it seems like the next natural step would be to make a programming language which is actually a spoken one. Take a look at Inform 7. It's not Python but does something similar to what you are describing: www.inform-fiction.org Check out the examples in the tutorial. Some of them are quite elegant. HTH /TA -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
The Music Guy writes: > ...might be translated as... > >>> Import the operating system module. http://coboloncogs.org -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Thu, Jan 15, 2009 at 5:02 PM, The Music Guy wrote:
> Just out of curiousity, have there been any attempts to make a version
> of Python that looks like actual English text? I mean, so much of Python
> is already based on the English language that it seems like the next
> natural step would be to make a programming language which is actually a
> spoken one.
>
> For example, the following code...
>
import os
def list_files(dirname):
for p in os.listdir(dirname):
print p
list_files("some_dir")
> foo
> bar
> etc
>
> ...might be translated as...
>
Import the operating system module.
Define a new function as "list files" which accepts
>"a path" and does the following:
>For every item in the list returned by the operating system's
>directory listing of the given path, do the following:
> Print the item.
List files from "some_dir".
> foo
> bar
> etc
Does the name "AppleScript" mean anything to you? ;-)
Cheers,
Chris
--
Follow the path of the Iguana...
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On Fri, Jan 16, 2009 at 11:02 AM, The Music Guy wrote:
> Just out of curiousity, have there been any attempts to make a version
> of Python that looks like actual English text? I mean, so much of Python
> is already based on the English language that it seems like the next
> natural step would be to make a programming language which is actually a
> spoken one.
>
> For example, the following code...
>
import os
def list_files(dirname):
for p in os.listdir(dirname):
print p
list_files("some_dir")
> foo
> bar
> etc
>
> ...might be translated as...
>
Import the operating system module.
Define a new function as "list files" which accepts
>"a path" and does the following:
>For every item in the list returned by the operating system's
>directory listing of the given path, do the following:
> Print the item.
List files from "some_dir".
> foo
> bar
> etc
>
>
> Obviously, creating a parser capable of handling such "code" would
> require a very good understanding not only of the English language but
> also of how ideas expressed in spoken languages are represented in terms
> that a computer can understand.
>
> A language like this would, of course, blow a lot of staple coding
> coding concepts like "variables," "objects," etc. right out of the
> water. I think, however, that it could be done, and wouldn't necessarily
> have to be any slower than any other scripting language as any text/code
> could be cached as bytecode, just like Python.
>
> I know it's sort of silly but I think something like this would be very
> interesting, maybe even useful. ^_^
You are mad :)
--JamesMills
--
http://mail.python.org/mailman/listinfo/python-list
English-like Python
Just out of curiousity, have there been any attempts to make a version
of Python that looks like actual English text? I mean, so much of Python
is already based on the English language that it seems like the next
natural step would be to make a programming language which is actually a
spoken one.
For example, the following code...
>>> import os
>>>
>>> def list_files(dirname):
>>> for p in os.listdir(dirname):
>>> print p
>>>
>>> list_files("some_dir")
foo
bar
etc
...might be translated as...
>>> Import the operating system module.
>>>
>>> Define a new function as "list files" which accepts
"a path" and does the following:
For every item in the list returned by the operating system's
directory listing of the given path, do the following:
Print the item.
>>>
>>> List files from "some_dir".
foo
bar
etc
Obviously, creating a parser capable of handling such "code" would
require a very good understanding not only of the English language but
also of how ideas expressed in spoken languages are represented in terms
that a computer can understand.
A language like this would, of course, blow a lot of staple coding
coding concepts like "variables," "objects," etc. right out of the
water. I think, however, that it could be done, and wouldn't necessarily
have to be any slower than any other scripting language as any text/code
could be cached as bytecode, just like Python.
I know it's sort of silly but I think something like this would be very
interesting, maybe even useful. ^_^
--
http://Alphaios.net - Tracked Module Music, Blog, and Links.
--
http://mail.python.org/mailman/listinfo/python-list
