RE: if does not evaluate

Discussion in 'Python' started by Robert Brewer, Jun 5, 2004.

  1. Jim Newton wrote:
    > A question that has bothered me ever since looking at python
    > the first time is that not everything evaluates to something.


    Are you only bothered by it because there's no ifelse operator? ;)

    > I am wondering what is the reason for this. Would making
    > everying evaluate have caused the langugage to be less
    > efficient execution-wise? or was it a choice to enforce some
    > sort of standard?


    Only Zen standards:

    1. Beautiful is better than ugly.
    2. Explicit is better than implicit.
    3. Simple is better than complex.
    6. Sparse is better than dense.
    7. Readability counts.

    > I've read a few discussions about the fact that there is
    > no if/then/else operartor.
    >
    > Wouldn't this problem be easily solved by making the built
    > in keywords actually be evaluatable.
    >
    > I.e., x = if something:
    > expr1
    > else:
    > expr2
    >
    > parentheses would of course be optional as they are for
    > all expressions.


    You'll first have to convince many people that this is a "problem" to be
    "solved". Why is your solution "better than":

    if something:
    x = expr1
    else:
    x = expr2

    Then you need to show why the alternatives aren't good enough:

    If your main desire is to code in some other language while still using
    Python, write your own VB-style IIf function:

    >>> def IIf(expression, truepart, falsepart):

    .... if expression:
    .... return truepart
    .... return falsepart
    ....
    >>> x = IIf('something', 'expr1', 'expr2')
    >>> x

    'expr1'

    If your main desire is to provide a one-liner, use a tuple (which is
    still ugly):

    >>> x = ('expr2', 'expr1')[bool('something')]
    >>> x

    'expr1'

    Or a mapping (which is prettier, but still uglier than the regular if:
    else:

    >>> x = {True: 'expr1',

    .... False: 'expr2'}[bool('something')]
    >>> x

    'expr1'

    Or a more generic morphing function:

    >>> def surjection(input, mappings):

    .... mappings = dict(mappings)
    .... return mappings[input]
    ....
    >>> x = surjection(bool('something'), {True: 'expr1', False: 'expr2'})
    >>> x

    'expr1'
    >>> x = surjection(bool('something'), [(True, 'expr1'), (False,

    'expr2')])
    >>> x

    'expr1'
    >>> x = surjection('something', [('something', 'expr1'), ('other',

    'expr2'), ('than', 'expr2')])
    >>> x

    'expr1'



    Robert Brewer
    MIS
    Amor Ministries
    Robert Brewer, Jun 5, 2004
    #1
    1. Advertising

  2. Robert Brewer

    Jim Newton Guest

    how do you put an if or a for inside a lambda?

    The expression i'm suggesting as evaluatable
    could be passable to a function call as well,
    as being mappable, or usable inside a lambda.
    It seems better to me in that it stops being
    a special case.

    E.g.,

    myfun( ( if cond1 expr1: else expr2 ),
    ( if cond2 expr3: else expr4 ))

    -jim

    >>
    >>I.e., x = if something:
    >> expr1
    >> else:
    >> expr2
    >>
    >>parentheses would of course be optional as they are for
    >>all expressions.

    >
    >
    > You'll first have to convince many people that this is a "problem" to be
    > "solved". Why is your solution "better than":
    >
    > if something:
    > x = expr1
    > else:
    > x = expr2
    >
    Jim Newton, Jun 6, 2004
    #2
    1. Advertising

  3. Robert Brewer

    Terry Reedy Guest

    "Jim Newton" <> wrote in message
    news:...
    > how do you put an if or a for inside a lambda?


    By wrapping them in other functions; otherwise you don't.

    lambda *args: expr #abbreviates (minus the function name)
    def f(*args): return expr

    If your function is more complicated than that, don't try to abbreviate.
    Use def.

    Terry J. Reedy
    Terry Reedy, Jun 6, 2004
    #3
  4. Robert Brewer

    Dan Bishop Guest

    Jim Newton <> wrote in message news:<>...
    > how do you put an if or a for inside a lambda?


    I'm not quite sure what you'd expect "for" to evaluate to, but you
    might want to take a look at list comprehensions:

    [expr(var) for var in seq if cond(var)]

    For "if", you can write "(F, T)[bool(C)]" or "(C and [T] or [F])[0]".
    The latter has the advantage of short-circuiting.
    Dan Bishop, Jun 6, 2004
    #4
  5. Robert Brewer

    Jim Newton Guest

    well, i accept the fact that python offers some simple
    concepts and you do a lot with simple concepts, but why
    can't you put an if inside a lambda? if "if" were evaluatable
    then you would be able to do that. it seems to me.

    lambda seem to work for very simple things but not for
    anything substantial.



    Terry Reedy wrote:
    > "Jim Newton" <> wrote in message
    > news:...
    >
    >>how do you put an if or a for inside a lambda?

    >
    >
    > By wrapping them in other functions; otherwise you don't.
    >
    > lambda *args: expr #abbreviates (minus the function name)
    > def f(*args): return expr
    >
    > If your function is more complicated than that, don't try to abbreviate.
    > Use def.
    >
    > Terry J. Reedy
    >
    >
    >
    >
    Jim Newton, Jun 7, 2004
    #5
  6. Robert Brewer

    Jim Newton Guest

    for compressions are quite nice but you are still pretty
    limited about what you can put inside the for. you cannot
    put any code otherwise acceptable in the language. For example
    what if i need two, three or four statements inside the for?

    another question, is why are "if" compressions not supported?

    x = [ if some_function() else some_other_function() ]

    or better

    x = [ if cond1():
    elsif cond2():
    else: cond3() ]

    whouldn't that be inkeeping with the compression syntax?


    -jim


    Dan Bishop wrote:
    > Jim Newton <> wrote in message news:<>...
    >
    >>how do you put an if or a for inside a lambda?

    >
    >
    > I'm not quite sure what you'd expect "for" to evaluate to, but you
    > might want to take a look at list comprehensions:
    >
    > [expr(var) for var in seq if cond(var)]
    >
    > For "if", you can write "(F, T)[bool(C)]" or "(C and [T] or [F])[0]".
    > The latter has the advantage of short-circuiting.
    Jim Newton, Jun 7, 2004
    #6
  7. Jim> lambda seem to work for very simple things but not for anything
    Jim> substantial.

    Right. Like Terry said, for anything more substantial use a named function.
    Lambda was never intended to be a replacement for def, and Python is
    fundamentally not a functional language (in the Haskell/Lisp sense of the
    term), so powerful anonymous functions are generally not needed. In fact,
    as list comprehensions and generator expressions take root, lambda's use
    dwindles.

    Skip
    Skip Montanaro, Jun 7, 2004
    #7
  8. Robert Brewer wrote:
    > If your main desire is to code in some other language while still using
    > Python, write your own VB-style IIf function:


    All the solutions you propose don't work (except the long form). You
    cannot code an "iif" function. Test:

    def iif(cond, expr1, expr2):
    if cond: return expr1
    return expr2
    def foo(x): return iif(x == 0, 0, 1.0/x)
    foo(4)
    foo(0)

    See PEP 308.

    Regards,
    Nicolas
    Nicolas Fleury, Jun 8, 2004
    #8
  9. Skip Montanaro <> writes:

    > Right. Like Terry said, for anything more substantial use a named function.
    > Lambda was never intended to be a replacement for def, and Python is
    > fundamentally not a functional language (in the Haskell/Lisp sense of the
    > term), so powerful anonymous functions are generally not needed.


    I wish people would stop making such self-fulfilling prophecies.

    You[*] don't use fully general anonymous closures, because the
    languages you use do not provide you that tool. Because such beasts,
    do not form part of your normal programming arsenal, you don't use
    them. Because you don't use them, you rarely see them used. Because
    you rarely see them used, you conclude that they are not needed. You
    you make the mistake of confusing your lack of imagination with some
    inherent quality of the language in question. The fact is that people
    who are used to using powerful programming techinques which you may
    not use yourself, _do_ miss their presence in languages in which you
    consider their absence to be a feature.

    Python has many qualities, but let's stop kidding ourselves that its
    current state is some sort of global optimum in the space of
    programming languages.

    In spite of its many qualities, Python has a number of
    shortcomings. Let's stop kidding ourselves that its shorcomings are
    features.

    Python's naff support for anonymous closures is a shortcoming, not a
    feature.


    [*] By "you" I mean "one", not "Skip Montanaro".
    Jacek Generowicz, Jun 9, 2004
    #9
  10. Robert Brewer

    Jim Newton Guest

    Jacek Generowicz wrote:
    > Because
    > you rarely see them used, you conclude that they are not needed. You
    > you make the mistake of confusing your lack of imagination with some
    > inherent quality of the language in question.


    very well said!!

    >
    >
    > In spite of its many qualities, Python has a number of
    > shortcomings. Let's stop kidding ourselves that its shorcomings are
    > features.
    >
    > Python's naff support for anonymous closures is a shortcoming, not a
    > feature.
    >
    >


    When i was a child, i thought as a child, and understood as a child,
    but when i became a man, i put childish things behind me.

    When i was a child, i only programmed in BASIC. At that time
    the only type of variables were global variables, there were no
    function definitions, and no recursion. i could not imagine
    that being a shortcomming, because i had never seen or used local
    varaibles, and i could handle GOTO quite easily.
    But i was very clever child, and did some powerful things
    with BASIC even with those restrictions.

    Python, being a simple and restrictive language as it is, is still
    quite nice and easy to learn. It is nice indeed, but lacks some
    features that could make it a much more elagant language.

    On the other hand perhaps the problem is not that Python has
    shortcomings, perhaps the real problem is that LISP is lacking
    lots of useful and mature UNIX and internet specific libraries.

    -jim

    --
    +------------------------------------------------------------------------+
    | Jim E. Newton () desk +49-(0)89-4563-1918 |
    | Methodology Services Europe fax +49-(0)89-4563-1819 |
    | Cadence Design Systems GmbH Munich Germany |
    | |
    | If you won't do it in the rain, you won't do it. |
    +------------------------------------------------------------------------+
    Jim Newton, Jun 9, 2004
    #10
  11. Robert Brewer

    Hung Jung Lu Guest

    Jacek Generowicz <> wrote:
    > Python has many qualities, but let's stop kidding ourselves that its
    > current state is some sort of global optimum in the space of
    > programming languages.
    >
    > In spite of its many qualities, Python has a number of
    > shortcomings. Let's stop kidding ourselves that its shorcomings are
    > features.


    ----------

    Totally agree.

    Two years ago or so, the Perl newsgroup/mailing-list overshadowed
    Python's newsgroup/mailing-list. Today, the opposite is true. When I
    started with Python, there was one single book, and it was not even
    available in most bookstore. Python has come a long way in popularity.

    However, some bad habits of Perl Mongers have been transplanted into
    the Python community. In particular, blind advocacy/worship, and
    refusal to hear/learn/see better features from other languages.

    In term of smartness or powerfulness, Python is only about average.
    Python is good because it kind of sits in the middle of many possible
    technological directions. But when you see comments from people that
    are bilingual in Python and other languages like Self/Io, Haskell,
    Lisp, etc., it's easy to see that Python is frankly kind of
    second-tier player, full of limitations and problems.

    regards,

    Hung Jung
    Hung Jung Lu, Jun 10, 2004
    #11
  12. Jim Newton <> wrote in message news:<>...
    > Jacek Generowicz wrote:
    > > Because
    > > you rarely see them used, you conclude that they are not needed. You
    > > you make the mistake of confusing your lack of imagination with some
    > > inherent quality of the language in question.

    >
    > very well said!!
    >
    > >
    > >
    > > In spite of its many qualities, Python has a number of
    > > shortcomings. Let's stop kidding ourselves that its shorcomings are
    > > features.
    > >
    > > Python's naff support for anonymous closures is a shortcoming, not a
    > > feature.
    > >
    > >

    >
    > When i was a child, i thought as a child, and understood as a child,
    > but when i became a man, i put childish things behind me.
    >
    > When i was a child, i only programmed in BASIC. At that time
    > the only type of variables were global variables, there were no
    > function definitions, and no recursion. i could not imagine
    > that being a shortcomming, because i had never seen or used local
    > varaibles, and i could handle GOTO quite easily.
    > But i was very clever child, and did some powerful things
    > with BASIC even with those restrictions.
    >


    *wipes a nostalgic tear from his eye*

    > Python, being a simple and restrictive language as it is, is still
    > quite nice and easy to learn. It is nice indeed, but lacks some
    > features that could make it a much more elagant language.
    >
    > On the other hand perhaps the problem is not that Python has
    > shortcomings, perhaps the real problem is that LISP is lacking
    > lots of useful and mature UNIX and internet specific libraries.
    >
    > -jim


    Python certainly has a number of problems; one of them is that it's
    possible to translate almost any sane language into Python virtually
    line by line. It's not the easiest way to do things, or the best,
    because you'll loose most of the places where Python really is more
    powerful in it's own right, and regard all of the places where Python
    differs from that language as obvious flaws. Maybe that's why the
    Python community has such a strong sense of what's 'idiomatic Python'.
    I still have to restrain myself from writing PyHaskell now and then.

    Lisp, I think, has two problems.

    Firstly an attitude among the community that actually *doing* anything
    is, well, beneath the language; after working through two books and
    several university courses on Lisp, going from the definition of eval
    to lexical vs dynamic scoping to macros to continuations, I suddenly
    realised that I had no idea how to open a file or do basic string
    manipulation. None of them condescended to sully themselves with such
    trivia.

    Secondly, Lisp's syntax doesn't parse well into the way people think,
    or vica versa. Python's does; in other words, it's executable
    pseudocode. Lisp, fundamentally, cannot change in this regard.

    Jam
    James Moughan, Jun 10, 2004
    #12
  13. (James Moughan) trolls:

    > Lisp, I think, has two problems.
    >
    > Firstly an attitude among the community that actually *doing* anything
    > is, well, beneath the language;


    Investigate the links in the sidebar on the left on

    http://www.franz.com/success/

    for a summary of the sort of stuff people actually *do* in Lisp.

    If you actually bothered to look before posting unfounded rubbish, you
    might have noticed that Lisp fans appreciate it exactly because it is
    extremely good for writing industrial programs in real-world
    situations.

    > after working through two books and several university courses on
    > Lisp, going from the definition of eval to lexical vs dynamic
    > scoping to macros to continuations, I suddenly realised that I had
    > no idea how to open a file or do basic string manipulation. None of
    > them condescended to sully themselves with such trivia.


    Maybe Lisp (and therefore Lisp books) are designed for intelligent
    people who want to solve hard problems, and it is assumed that
    intelligent people can look up trivia like how to open files in the
    language standard (); maybe books are considered necessary to teach
    you the difficult things which you cannot read between the lines of
    the standard.

    Maybe you read the wrong books and go to the wrong universities, at
    least for your sort of mind. The following book, still in the process
    of being written, might be more to your liking:

    http://www.gigamonkeys.com/book/

    Note the title: _Practical Common Lisp_.

    > Secondly, Lisp's syntax doesn't parse well into the way people
    > think,


    .... after 20 seconds of thought.

    If you actually try using Lisp, as a programming language for writing
    real-world programs, rather than as something to troll about, then you
    will find that Lisp's syntax matches very closely the way people
    think: they start thinking about source code as a tree structure
    rather than a series of tokens. This takes us back to the original
    point I made upthread. Just because your tools don't provide you with
    the ability to do something, thereby ensuring that you don't do it,
    does not mean that doing it is a bad idea, or that not being able to
    do it is a language feature.

    Lisp allows you to think of program source as a tree. "Source is a
    series of tokens" languages seriously limit the way you think about
    your program: this is a shortcoming, not a feature.

    Don't conclude, just because the tools you use limit you in some way,
    that escaping those limitations is somehow undesirable.
    Jacek Generowicz, Jun 10, 2004
    #13
  14. Robert Brewer

    Peter Otten Guest

    Hung Jung Lu wrote:

    > Jacek Generowicz <> wrote:
    >> Python has many qualities, but let's stop kidding ourselves that its
    >> current state is some sort of global optimum in the space of
    >> programming languages.


    A local optimum. You could argue that properties and decorators, maybe list
    comprehensions, are a step away from that.

    >> In spite of its many qualities, Python has a number of
    >> shortcomings. Let's stop kidding ourselves that its shorcomings are
    >> features.


    I'm confident that Python's developers are well aware of the tradeoffs they
    make.

    > Totally agree.
    >
    > Two years ago or so, the Perl newsgroup/mailing-list overshadowed
    > Python's newsgroup/mailing-list. Today, the opposite is true. When I
    > started with Python, there was one single book, and it was not even
    > available in most bookstore. Python has come a long way in popularity.
    >
    > However, some bad habits of Perl Mongers have been transplanted into
    > the Python community. In particular, blind advocacy/worship, and
    > refusal to hear/learn/see better features from other languages.


    Pythonistas know that piling up all the best of breed features will not
    result in the best language ever.

    > In term of smartness or powerfulness, Python is only about average.


    How did you measure that?

    > Python is good because it kind of sits in the middle of many possible
    > technological directions. But when you see comments from people that
    > are bilingual in Python and other languages like Self/Io, Haskell,
    > Lisp, etc., it's easy to see that Python is frankly kind of
    > second-tier player, full of limitations and problems.


    Are there any languages without limitations? If so, that might be the
    problem of those languages.

    It is easy to claim that Python is bad and could be better, the hard thing
    is to make the concrete steps in the evolvement of the language and
    hopefully avoid the impasses. If you have to make contributions to that,
    write a PEP, hack a demo implementation, and I'm sure the Python developers
    will listen.

    Peter
    Peter Otten, Jun 10, 2004
    #14
  15. Robert Brewer

    Hung Jung Lu Guest

    (James Moughan) wrote:
    > I still have to restrain myself from writing PyHaskell now and then.


    Maybe it's time to try with some simple prototype.

    > Secondly, Lisp's syntax doesn't parse well into the way people think,
    > or vica versa. Python's does; in other words, it's executable
    > pseudocode. Lisp, fundamentally, cannot change in this regard.


    But Python does have serious problems when one goes to the next level
    of software development. I guess that's why Io and Prothon were born.
    Python is at the stage where you need a fresh re-incarnation to go to
    the next level.

    There are a few directions that need to be explorered, and I am not
    sure creating a real new language is the way to go. I've seen it in
    Io, where once you set things in stone, it becomes just another Python
    with problems that will stay forever. I guess right now it's not the
    moment of creating more languages and set things in stone. It's
    probably better to have some toy languages or language prototypes to
    explorer ideas. Collect enough ideas and experience, and probably
    leave the rest to the next generation of people.

    Frankly, I see a few camps: (a) Lisp and AOP folks, (b) Functional
    folks, (c) Prototype-based folks. Because these are very specialized
    fields, very few people seem to be native speakers of all three of
    them. The next killer language will have to incorporate lessons learnt
    from all three camps. It's a daunting task. It's best to have some toy
    languages... like scaled-down model airplanes, or even just the model
    airplane parts, before one actually build the real thing.

    regards,

    Hung Jung
    Hung Jung Lu, Jun 10, 2004
    #15
  16. Robert Brewer

    Jim Newton Guest


    >>Secondly, Lisp's syntax doesn't parse well into the way people
    >>think,

    >
    >


    not sure i understand what you mean by "not the way people think",
    but i think i disagree with you. lisp seems to be very similar
    to the way people think, it is just that programmers have learned
    over the years to think in a algol type way.

    For example, if you have a bag of balls, and you want to find out
    if one of them is red. The algol type way would be

    for ball in bag-of-balls
    is ball red?
    yes ==> set flag true
    no ==> keep going
    Is flag true?
    yes ==> there is a red ball
    no ==> there is no red ball


    but that seems like a very different way than people think.
    the lisp way to answer the question is

    is there a ball in the bag that matches condition?
    condition being: is the ball red?

    It seems like a much more natural way to think... at least to me.
    -jim
    Jim Newton, Jun 10, 2004
    #16
  17. Robert Brewer

    Terry Reedy Guest

    "Jacek Generowicz" <> wrote in message
    news:...
    > Maybe you read the wrong books and go to the wrong universities, at
    > least for your sort of mind. The following book, still in the process
    > of being written, might be more to your liking:
    >
    > http://www.gigamonkeys.com/book/


    I read the first 7 chapters. I found it easier going, as I remember, than
    Graham's book. I liked the author's habit of drawing parallels to other
    languages, including Python. As a result, I improved my understanding of
    certain points about programing. Thanks for the reference.

    I also remain convinced that, in some ways important to *me*, Lisp is
    clutzier than Python, and that I have insufficient reason to pursue it in
    practice at this time. To each their preference.

    Terry J. Reedy
    Terry Reedy, Jun 10, 2004
    #17
  18. Jacek Generowicz <> wrote in message news:<>...
    > (James Moughan) trolls:
    >
    > > Lisp, I think, has two problems.
    > >
    > > Firstly an attitude among the community that actually *doing* anything
    > > is, well, beneath the language;

    >
    > Investigate the links in the sidebar on the left on
    >
    > http://www.franz.com/success/
    >
    > for a summary of the sort of stuff people actually *do* in Lisp.
    >
    > If you actually bothered to look before posting unfounded rubbish, you
    > might have noticed that Lisp fans appreciate it exactly because it is
    > extremely good for writing industrial programs in real-world
    > situations.
    >


    I have no doubt that Lisp can be extremely practical as a language.
    I'm expressing a slightly humorous characterization of the attitude of
    parts of the Lisp community, especially in academia.

    > > after working through two books and several university courses on
    > > Lisp, going from the definition of eval to lexical vs dynamic
    > > scoping to macros to continuations, I suddenly realised that I had
    > > no idea how to open a file or do basic string manipulation. None of
    > > them condescended to sully themselves with such trivia.

    >
    > Maybe Lisp (and therefore Lisp books) are designed for intelligent
    > people who want to solve hard problems, and it is assumed that
    > intelligent people can look up trivia like how to open files in the
    > language standard (); maybe books are considered necessary to teach
    > you the difficult things which you cannot read between the lines of
    > the standard.
    >
    > Maybe you read the wrong books and go to the wrong universities, at
    > least for your sort of mind.


    Strange, I've always worked the other way around. For the extremely
    simple, basic things it seems like *slight* overkill to refer to the
    ansi standard. For complex issues I'd rather have a formal language
    document that tells me exactly what's going on, rather than someone
    blathering for 50 pages.

    In this case, I merely found it particularly striking that a subject
    like file i/o, which would be considered basic and important in most
    languages, seemed to be in many Lispers' 'blind spot'.

    Lisp is, without doubt, the most interesting language around in terms
    of pure theory. The corollary to that, I guess, is that it attracts a
    lot of pure theorists.

    > The following book, still in the process
    > of being written, might be more to your liking:
    >
    > http://www.gigamonkeys.com/book/
    >
    > Note the title: _Practical Common Lisp_.
    >


    Yes, I'm aware that there's some stuff on the more practical side; the
    Lisp Cookbook isn't too bad either. But it's definitely not the norm,
    and you have to dig quite a bit. No problem, I'm a persistent git.

    > > Secondly, Lisp's syntax doesn't parse well into the way people
    > > think,

    >
    > ... after 20 seconds of thought.
    >
    > If you actually try using Lisp, as a programming language for writing
    > real-world programs, rather than as something to troll about, then you
    > will find that Lisp's syntax matches very closely the way people
    > think: they start thinking about source code as a tree structure
    > rather than a series of tokens.



    Not really, no. People think about programs tree-style where certain
    control structures occur, and virtually all languages nest at those
    points. However, not in cases like assignment and mathematical
    expressions, where Lisp would still tend to mandate it. That sort of
    deeply nested code is often the most unreadable.

    Also Lisp usually nests somewhat uncomfortably, e.g. in an if
    statement

    (if (< i 0)
    (* -1 i)
    i)

    There's simply no context there for the eye to pick up on. Nest all
    of that a couple of layers deeper and it's going to become annoying.
    That's the trouble with having an extremely regular, simple system. I
    guess it makes building the AST easy, though. ;)

    I am not trolling about Lisp, btw. I'm expressing my experiences of
    playing around with Lisp as a new language. My intention was more in
    the line of amusement.

    And, frankly, if you think that a mildly sarcastic comment about some
    of the learning materials for Lisp, along a bold statement that Lisp
    doesn't have the world's most intuitive syntax is a viscous, trollish
    slur on the language, justifying random personal attacks, then you
    really need to get a freaking life.


    >This takes us back to the original
    > point I made upthread. Just because your tools don't provide you with
    > the ability to do something, thereby ensuring that you don't do it,
    > does not mean that doing it is a bad idea, or that not being able to
    > do it is a language feature.
    >
    > Lisp allows you to think of program source as a tree. "Source is a
    > series of tokens" languages seriously limit the way you think about
    > your program: this is a shortcoming, not a feature.
    >
    > Don't conclude, just because the tools you use limit you in some way,
    > that escaping those limitations is somehow undesirable.


    It's quite possible to build a program as a set of recursive functions
    in just about any language, if you *wish* to build it as a tree
    structure. In fact I do that pretty often, where a problem happens to
    be best expressed in that way. However Lisp pretty much forces you
    into one way of doing things. That's a shortcoming, not a feature.
    The *advantage* of that shortcoming is that it allows you to blur or
    eliminate the distinction between program code and data; that's where
    Lisp gets it's power from. It's a trade-off, like most language
    design issues.

    Lisp has an extremely natural form for certain problems. Handling
    HTML and XML is one of those, and Lisp should really have squeezed
    into in many of the gaps currently filled by Java. (Yes, there have
    been companies doing this highly successfully; not many, though.)

    But different problems may - shock - be better expressed through
    different languages, and diferent syntaxes.
    James Moughan, Jun 10, 2004
    #18
  19. Jim Newton <> wrote in message news:<>...
    > >>Secondly, Lisp's syntax doesn't parse well into the way people
    > >>think,

    > >
    > >

    >
    > not sure i understand what you mean by "not the way people think",
    > but i think i disagree with you. lisp seems to be very similar
    > to the way people think, it is just that programmers have learned
    > over the years to think in a algol type way.
    >
    > For example, if you have a bag of balls, and you want to find out
    > if one of them is red. The algol type way would be
    >
    > for ball in bag-of-balls
    > is ball red?
    > yes ==> set flag true
    > no ==> keep going
    > Is flag true?
    > yes ==> there is a red ball
    > no ==> there is no red ball
    >
    >
    > but that seems like a very different way than people think.
    > the lisp way to answer the question is
    >
    > is there a ball in the bag that matches condition?
    > condition being: is the ball red?
    >
    > It seems like a much more natural way to think... at least to me.
    > -jim


    Undeniably, Lisp has some useful routines. Especially for LISt
    Processing. :)However, let's rewrite this how I might put it in
    Python;

    def has_elem(lis, cond):
    for x in lis:
    if cond(x):
    return True
    return False

    which, to me, says; check each element of the list, if it fulfils the
    condition, be true. If none fulfilled the condition, be false.
    Logical enough. If I were checking through a deck of cards to see if
    there were any Jokers then that's what I'd do.

    Now, how to do this in Lisp. There are several functions for applying
    a function to the elements of a list to select them, though AFAIK none
    specifically for our purpose. I may very well be wrong there
    o'course. One way is:

    (define has-element (cond list)
    (equal () (member-if #'cond list))))

    Well, it's definitely short. It doesn't exactly translate well,
    though; search the list for a sub-list that starts with an element
    which evaluates to true under cond. Evaluate to the equality of that
    list with the null list. Hmmm.

    That's not a great example, although it's probably how I'd write it :)
    so let's do a real function:

    (defun has-element (pred lis)
    (if (equal lis ())
    NIL
    (if (funcall pred (car lis))
    T
    (has-element pred (cdr lis)))))

    Rough translation; if the list is the null list, return NIL (false).
    Otherwise, if applying pred to the first element of the list is true,
    be T (true), otherwise, evaluate to the value of this function applied
    to pred and the list excluding the first element.

    This isn't really too complex. However, it's not how most people
    *think* about a job like searching a list; mentally, searching is a
    single block task, not a recursive function.

    There are some other obvious issues with syntax. The brain wasn't
    meant to pick up on structure in arbitrary numbers of parenthesis, and
    I wouldn't even try to write Lisp without a highlighting editor. car
    and cdr might as well be in greek. (yes, I know I can redefine them;
    first thing I did). We have to have a rather arbitrary #' funcall and
    syntax to stop a function evaluating long enough to shift it to where
    it's useful.

    None of these are anything like fatal flaws. When I'm programming in
    Python, though, concepts seem to just flow naturally onto the screen.
    I don't think that's entirely 'what I know', either, because it began
    happening within a day or two, and my style in Python is quite
    different to in most other languages.

    Hmm, long answer to a short question. I hope you see what I mean,
    though. Lisp is a powerful language, but pragmatically, Python lets
    me just get on with what I'm doing.
    James Moughan, Jun 11, 2004
    #19
  20. (Hung Jung Lu) wrote in message news:<>...
    > (James Moughan) wrote:
    > > I still have to restrain myself from writing PyHaskell now and then.

    >
    > Maybe it's time to try with some simple prototype.
    >
    > > Secondly, Lisp's syntax doesn't parse well into the way people think,
    > > or vica versa. Python's does; in other words, it's executable
    > > pseudocode. Lisp, fundamentally, cannot change in this regard.

    >
    > But Python does have serious problems when one goes to the next level
    > of software development. I guess that's why Io and Prothon were born.
    > Python is at the stage where you need a fresh re-incarnation to go to
    > the next level.
    >


    I'm curious as to what those problems are, and what the 'next leve'
    is; there are definitely warts, and some, like the scoping rules, get
    in the way occasionally, but by and large there's nothing that can't
    be worked around. It lacks severely in compile-time metaprogramming,
    but has some very nice run-time features, which are arguably better in
    a language which isn't too focussed on performance.

    > There are a few directions that need to be explorered, and I am not
    > sure creating a real new language is the way to go. I've seen it in
    > Io, where once you set things in stone, it becomes just another Python
    > with problems that will stay forever. I guess right now it's not the
    > moment of creating more languages and set things in stone. It's
    > probably better to have some toy languages or language prototypes to
    > explorer ideas. Collect enough ideas and experience, and probably
    > leave the rest to the next generation of people.
    >
    > Frankly, I see a few camps: (a) Lisp and AOP folks, (b) Functional
    > folks, (c) Prototype-based folks. Because these are very specialized
    > fields, very few people seem to be native speakers of all three of
    > them. The next killer language will have to incorporate lessons learnt
    > from all three camps. It's a daunting task. It's best to have some toy
    > languages... like scaled-down model airplanes, or even just the model
    > airplane parts, before one actually build the real thing.
    >


    There are a lot of interesting ideas out there - personally I'd like
    to see Stepanov cease being so notoriously lazy and write the language
    C++ could have been. :) We'll probably find different paradigms being
    useful in different contexts, and to different people. After all, how
    boring would the world be if you only ever needed to learn one
    language?

    Jam

    > regards,
    >
    > Hung Jung
    James Moughan, Jun 11, 2004
    #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. Rick Osborn
    Replies:
    10
    Views:
    3,938
    Jon A. Cruz
    Feb 8, 2004
  2. kushalsoftpro
    Replies:
    6
    Views:
    2,170
    John Harrison
    Nov 4, 2004
  3. Jim Newton

    if does not evaluate

    Jim Newton, Jun 5, 2004, in forum: Python
    Replies:
    8
    Views:
    281
    Tor Iver Wilhelmsen
    Jun 8, 2004
  4. Abhi
    Replies:
    7
    Views:
    2,465
  5. KevinSimonson
    Replies:
    6
    Views:
    822
    Bo Persson
    Oct 23, 2010
Loading...

Share This Page