Any advantage in LISPs having simpler grammars than Python?

Discussion in 'Python' started by seberino@spawar.navy.mil, Mar 7, 2006.

  1. Guest

    Is there any advantage to a language having a nice mathematically
    compact grammar like LISP does? (or at least used to?)

    Many have admired the mathematically simple grammar of LISP
    in which much of the language is built up from conses IIRC.

    Python's grammar seems complicated by comparison.

    Is this anything to worry about?

    Chris
     
    , Mar 7, 2006
    #1
    1. Advertising

  2. On 2006-03-07, <> wrote:

    > Is there any advantage to a language having a nice mathematically
    > compact grammar like LISP does? (or at least used to?)


    Yes. Grammars like LISP's make it easy for programs to
    generate and read code. Grammars like Python's make it easy for
    humans to generate and read code.

    > Many have admired the mathematically simple grammar of LISP
    > in which much of the language is built up from conses IIRC.
    >
    > Python's grammar seems complicated by comparison.


    People are pretty good at complicated grammars if they're well
    designed (people seem to like grammars with a fair bit of
    redundancy), and can be amazingly bad at simple grammars.

    > Is this anything to worry about?


    That depends. Are you a computer program or a person? If the
    former, LISP is definitely for you. If the latter, then I'd
    recommend Python.

    (And I used to write real-world apps in Scheme before I
    discovered Python).

    --
    Grant Edwards grante Yow! I think my CAREER
    at is RUINED!!
    visi.com
     
    Grant Edwards, Mar 7, 2006
    #2
    1. Advertising

  3. Douglas Alan Guest

    Terry Hancock <> writes:

    > I think experienced Lisp programmers must learn to visually parse
    > the *words* in the Lisp program to determine the structure, but I
    > find that really unhelpful, myself.


    Experienced Lisp programmers use indentation to visually parse the
    program structure, just like Python programmers do for Python.
    Experienced Lisp programmers learn to not see the parentheses when
    they don't need to.

    When I did a lot of Lisp programming, I often felt that it would be
    kind of nice to have a version of Lisp that would infer many of the
    parentheses from indentation, so that you could elide most of them.
    But then again, the parentheses are very easy for an experienced Lisp
    programmer to ignore, so such a change would have been a very hard
    sell.

    |>oug
     
    Douglas Alan, Mar 7, 2006
    #3
  4. On Tuesday 07 March 2006 04:21 pm, wrote:
    > Is there any advantage to a language having a nice mathematically
    > compact grammar like LISP does? (or at least used to?)
    > Many have admired the mathematically simple grammar of LISP
    > in which much of the language is built up from conses IIRC.
    > Python's grammar seems complicated by comparison.
    >
    > Is this anything to worry about?


    Certainly I'm not going to lose any sleep over it. ;-)

    I think the cool thing about Lisp's tiny grammar is that it
    proves you can make a grammar that small work. It's
    minimalist to the extreme.

    The trouble is, while it may be easy for the machine to parse,
    it isn't the machine's clerical ability we are worried about!

    Ultimately any such determination is aesthetic, so there will
    inevitably be disagreement, but for some of us, at least, the
    Python syntax is a much better balance between simplicity and
    adequate discrimination and visual cues.

    Perl, for example, is much further along on that spectrum -- it
    has a large number of "punctuation" symbols (symbolic operators,
    really). Lots of "visual cues", but it's not simple at all.

    The nice thing about symbolic operators is that they are very
    compact and very easy to distinguish from one another. The bad
    thing about them is that they are not as easy to remember as
    words, and they are very difficult to look up, compared to
    words. Therefore, you have to "just know" what they mean.

    Or rather -- learning them is part of comprehending the core
    language, as opposed to something you learn as you go along.

    Word symbols, like Python's keywords, standard library functions,
    classes, and methods are easier to look up in the manual if you
    get stuck. They also put user constructs on a much more even
    footing with things built into the language. So -- I don't have
    to write a PEP if I just want a useful feature I can implement
    in a module. Using that approach, I can construct a "domain
    specific language" in python or lisp. In a way, that's what all
    modules do (at least they allow you to expand the vocabulary of
    the language, though most leave the grammar alone).

    Lisp gives you that kind of power to the nines. It lets you
    rewrite the vocabulary, grammar, and whatever to get the job
    done the way you want.

    And then people use it. And that leaves you, as the end user, to
    learn a new language for each application. And the extremely
    limited grammar means that there are few visual cues to sort out
    what is part of Lisp, what is part of a library, and what is your
    own code. It's like a paper without hierarchical heading styles.
    You can read it, but it's not as easy as one which is structured
    with visual cues as to what is a heading, what is a section number,
    what is emphasized, etc.

    Some people apparently love Lisp, but I really could never get
    over the nested parentheses making my eyes cross. ;-)

    I think experienced Lisp programmers must learn to visually
    parse the *words* in the Lisp program to determine the structure,
    but I find that really unhelpful, myself.

    Remember that you *can* represent your program with nothing but
    two characters, "0" and "1" -- even simpler than Lisp. That
    doesn't mean that that's the "preferred form for editing" it. ;-)

    Cheers,
    Terry

    --
    Terry Hancock ( hancock at anansispaceworks.com )
    Anansi Spaceworks http://www.anansispaceworks.com
     
    Terry Hancock, Mar 7, 2006
    #4
  5. Paul Rubin Guest

    Douglas Alan <> writes:
    > Experienced Lisp programmers use indentation to visually parse the
    > program structure, just like Python programmers do for Python.
    > Experienced Lisp programmers learn to not see the parentheses when
    > they don't need to.



    The OP might find this interesting: http://www.norvig.com/python-lisp.html

    > When I did a lot of Lisp programming, I often felt that it would be
    > kind of nice to have a version of Lisp that would infer many of the
    > parentheses from indentation, so that you could elide most of them.
    > But then again, the parentheses are very easy for an experienced Lisp
    > programmer to ignore, so such a change would have been a very hard
    > sell.


    "Super parens" were present in a few old Lisp dialects but these days
    I think most Lisp programmers use editors that balance regular parens
    automatically, so that when you type a closing paren, the editor
    highlights the matching open paren or the cursor briefly visits it.
    RMS first implemented this feature in the 1970's or so, and says that
    within weeks of starting to use it, he lost the ability to count
    parentheses manually. He inferred that since he lost the ability so
    fast, counting parentheses must have been taking up a considerable
    amount of his mental resources, which were now freed up for other
    things.

    With automatic paren balancing, the parentheses in Lisp aren't really
    bothersome. Lisp itself (to me at least) has gotten to feel clunky
    and old-fashioned over the years. Of course, a new incarnation could
    appear.

    www.lemonodor.com is a good blog where Lisp geeks hang out. Lots of
    interesting things (not just Lisp related) get posted there.
     
    Paul Rubin, Mar 8, 2006
    #5
  6. Douglas Alan Guest

    Grant Edwards <> writes:

    > On 2006-03-07, <> wrote:


    >> Is there any advantage to a language having a nice mathematically
    >> compact grammar like LISP does? (or at least used to?)


    Yes, Lisp's syntax allows for a very powerful macro mechanism that is
    extremely useful.

    > Yes. Grammars like LISP's make it easy for programs to generate and
    > read code. Grammars like Python's make it easy for humans to
    > generate and read code.


    I find Lisp to be perfectly readable. In fact, in some ways I find it
    to be more readable than any other language, including Python. I
    like, for instance, the prefix notation, since then I can identify the
    sort of expression that I am looking at without having to look ahead
    into the expression.

    For instance, if Python were to have been designed so that you would
    write:

    let myVeryLongVariableName = 3

    I would have preferred this over

    myVeryLongVariableName = 3

    With the latter, I have to scan down the line to see that this line is
    in an assignment statement.

    (This problem is significantly worse in C++, where variable
    declarations can be rather difficult to visually parse, unless all
    classes begin with capital letters and nothing else does.)

    >> Many have admired the mathematically simple grammar of LISP
    >> in which much of the language is built up from conses IIRC.


    >> Python's grammar seems complicated by comparison.


    >> Is this anything to worry about?


    No, not really. Not unless you want a powerful macro facility or you
    want to programmatically analyze or manipulate your software.

    |>oug
     
    Douglas Alan, Mar 8, 2006
    #6
  7. Grant Edwards <> writes:

    > Yes. Grammars like LISP's make it easy for programs to
    > generate and read code. Grammars like Python's make it easy for
    > humans to generate and read code.


    The above statement sounds too generalized to me. IMHO it's more of a
    matter of preference, your mindset and what you're accustomed to.


    br,
    S

    --
    -- Today is the car of the cdr of your life.
     
    Simo Melenius, Mar 8, 2006
    #7
  8. Carl Banks Guest

    Douglas Alan wrote:
    > For instance, if Python were to have been designed so that you would
    > write:
    >
    > let myVeryLongVariableName = 3
    >
    > I would have preferred this over
    >
    > myVeryLongVariableName = 3
    >
    > With the latter, I have to scan down the line to see that this line is
    > in an assignment statement.


    Interesting. I always found that the visual distinctness of non-Lisp
    programs made it easier to scan. For example, in Python I could blur my
    eyes such that I can't positively identify the letters, but could still
    tell an assignment from a function call from a mathemetical expression;
    not so easy in LISP where expressions are visually similar. Thus, a
    line in Python would require less reading, and thus less effort. Or so
    it is for me.

    Apparently, I look at the whole line, whereas you look at only the
    begining of the line when scanning. I suppose many LISPers do as well.
    I guess which is less effort depends on whether you find it more
    difficult to identify patterns whole line, or read an extra word.

    Carl Banks
     
    Carl Banks, Mar 8, 2006
    #8
  9. Douglas Alan wrote:

    > Experienced Lisp programmers use indentation to visually parse the
    > program structure, just like Python programmers do for Python.
    > Experienced Lisp programmers learn to not see the parentheses when
    > they don't need to.


    True, and this is IMHO an advantage of lisp to python (both humans
    and computers get something they are good at parsing, and mistakes
    in the one can be corrected using the other).

    > When I did a lot of Lisp programming, I often felt that it would be
    > kind of nice to have a version of Lisp that would infer many of the
    > parentheses from indentation, so that you could elide most of them.


    This is not necessary - just making them barely visible suffices.

    (font-lock-add-keywords
    'emacs-lisp-mode
    '(("[()]" . somr-barely-visible-face)))

    One can also use nil instead of the mode, wrap the thing into a
    defun and use it as a hook (nil means "just the current buffer
    whatever mode it is in").

    Btw., vim seems to try to become a real editor - look at
    http://wiki.alu.org/Vim_ECL

    Ralf
     
    Ralf Muschall, Mar 8, 2006
    #9
  10. Douglas Alan Guest

    "Carl Banks" <> writes:

    > Douglas Alan wrote:
    >
    >> For instance, if Python were to have been designed so that you would
    >> write:
    >>
    >> let myVeryLongVariableName = 3
    >>
    >> I would have preferred this over
    >>
    >> myVeryLongVariableName = 3
    >>
    >> With the latter, I have to scan down the line to see that this line is
    >> in an assignment statement.

    >
    > Interesting. I always found that the visual distinctness of non-Lisp
    > programs made it easier to scan. For example, in Python I could blur my
    > eyes such that I can't positively identify the letters, but could still
    > tell an assignment from a function call from a mathemetical expression;
    > not so easy in LISP where expressions are visually similar.


    Hey, well I designed my own programming language "Drawl" that combines
    the best of both worlds. A sample program in Drawl would look
    something like this:

    proc mostApplicableMethods (g args)
    let appMethods = (filter [lambda (met) (mcProtoMetApp? met lex:args)]
    (funMets g))
    let nMets = (len appMethods)
    if nMets = 1; appMethods
    elif nMets = 0; %{}
    else let retval = {}
    for i in (range nMets)
    let m1 = appMethods
    for m2 in retval + appMethods[i+1..inf]
    if (isCongruentTo? m2 m1); break
    else (append list=retval ele=m1)
    retval

    This would correspond to the following Python code:

    def mostApplicableMethods(g, args):
    appMethods = filter(lambda met: isMcProtoMetApp(met, args),
    funMets(g))
    nMets = len(appMethods)
    if nMets == 1: return appMethods
    elif nMets == 0: return ()
    else:
    retval = []
    for i in range(nMets):
    m1 = appMethods
    for m2 in retval + appMethods[i+1:]:
    if isCongruentTo(m2, m1): break
    else: retval.append(m1)
    return retval

    In Drawl all expressions are either functions calls that begin with a
    "(" and are Lisp-like, or they are mathematical infix expressions.
    Statements and macros, on the other hand, always begin with an
    identifier that identifies the statement or macro. The exception to
    what I just said is that statements and macros can be turned into
    expressions by surrounding them with square brackets.

    Too bad I never got around to actually implementing Drawl, though,
    because we all know that what the world needs right now is another
    programming language....

    |>oug
     
    Douglas Alan, Mar 8, 2006
    #10
    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. Jon Slaughter

    Grammars for C++

    Jon Slaughter, Jul 5, 2005, in forum: C++
    Replies:
    6
    Views:
    464
  2. Sohail
    Replies:
    0
    Views:
    894
    Sohail
    Aug 12, 2010
  3. Michael Judge

    Grammars (mini-scripting languages)

    Michael Judge, Feb 2, 2006, in forum: Ruby
    Replies:
    5
    Views:
    183
    Harley Pebley
    Feb 6, 2006
  4. Phil Tomson
    Replies:
    3
    Views:
    121
    Clifford Heath
    Feb 29, 2008
  5. George George

    formal and stochastic grammars in ruby

    George George, Aug 4, 2009, in forum: Ruby
    Replies:
    2
    Views:
    136
    George George
    Aug 5, 2009
Loading...

Share This Page