Re: English-like Python

Discussion in 'Python' started by The Music Guy, Jan 18, 2009.

  1. 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.
     
    The Music Guy, Jan 18, 2009
    #1
    1. Advertising

  2. The Music Guy

    Aaron Brady Guest

    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.
     
    Aaron Brady, Jan 20, 2009
    #2
    1. Advertising

  3. The Music Guy

    Joe Strout Guest

    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
     
    Joe Strout, Jan 20, 2009
    #3
  4. The Music Guy

    Aaron Brady Guest

    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.
     
    Aaron Brady, Jan 20, 2009
    #4
  5. The Music Guy

    Joe Strout Guest

    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
     
    Joe Strout, Jan 20, 2009
    #5
  6. The Music Guy

    MRAB Guest

    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! :)
     
    MRAB, Jan 20, 2009
    #6
  7. The Music Guy

    Terry Reedy Guest

    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.
     
    Terry Reedy, Jan 21, 2009
    #7
  8. The Music Guy

    MRAB Guest

    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')
     
    MRAB, Jan 21, 2009
    #8
  9. 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
     
    Steven D'Aprano, Jan 21, 2009
    #9
  10. The Music Guy

    Aaron Brady Guest

    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.
     
    Aaron Brady, Jan 21, 2009
    #10
  11. The Music Guy

    Aaron Brady Guest

    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".
     
    Aaron Brady, Jan 21, 2009
    #11
  12. The Music Guy

    Joe Strout Guest

    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
     
    Joe Strout, Jan 21, 2009
    #12
  13. The Music Guy

    Aaron Brady Guest

    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.
     
    Aaron Brady, Jan 21, 2009
    #13
  14. 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
     
    Steven D'Aprano, Jan 22, 2009
    #14
  15. 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
     
    Steven D'Aprano, Jan 22, 2009
    #15
  16. The Music Guy

    Aaron Brady Guest

    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.
     
    Aaron Brady, Jan 22, 2009
    #16
  17. The Music Guy

    Aaron Brady Guest

    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.
     
    Aaron Brady, Jan 22, 2009
    #17
  18. The Music Guy

    Joe Strout Guest

    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
     
    Joe Strout, Jan 22, 2009
    #18
  19. 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.
     
    Adelle Hartley, Feb 2, 2009
    #19
  20. The Music Guy

    Steve Holden Guest

    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/
     
    Steve Holden, Feb 3, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?UmFlZCBTYXdhbGhh?=

    English/English DLL

    =?Utf-8?B?UmFlZCBTYXdhbGhh?=, Oct 15, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    1,710
    =?Utf-8?B?UmFlZCBTYXdhbGhh?=
    Oct 16, 2005
  2. IchBin
    Replies:
    1
    Views:
    810
  3. The Music Guy

    English-like Python

    The Music Guy, Jan 16, 2009, in forum: Python
    Replies:
    10
    Views:
    566
  4. Chris Rebert

    Re: English-like Python

    Chris Rebert, Jan 16, 2009, in forum: Python
    Replies:
    2
    Views:
    332
    Tim Rowe
    Jan 17, 2009
  5. Roger Pack
    Replies:
    3
    Views:
    122
    Roger Pack
    Aug 19, 2008
Loading...

Share This Page