merits of Lisp vs Python

[Mark Tarver]

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

[Bruno Desthuilliers]

Paul Rubin a écrit :

Bruno Desthuilliers <bd************ *****@free.quel quepart.frwrite s:

>>Strictly speaking, only first-class functions are required, and
tail-recursion optimisation is only an implentation detail. Now it's
obvious that when it comes to real-life-size programs, this is a
*very* important detail !-)

I don't buy this.

Fine - I'm not trying to sell it !-)

One of my favorite quotes about specifications
(http://www.sgi.com/tech/stl/drdobbs-interview.html):

(snip).

From a purely logical POV, the fact that a stack implementation has
constant-time access or not is totally irrelevant (real-time problems
set aside). This doesn't mean it's not important in practice.

[greg]

Bill Atkins wrote:

This is not a response to any particular post, but rather to the
general argument that macros are not as useful as we Lispers claim.

Here is a fairly complete GUI RSS reader in 90 lines of Lisp

For comparison, here's how something with a similar
API might be used from Python.

class RSSInterface(In terface):

def __init__(self):
Interface.__ini t__(self,
panes = [
TextInput('url_ pane',
title = 'Feed URL:',
callback = 'add_feed',
callback_type = 'interface'),
PushButton('add ',
text = 'Add Feed',
callback = 'add_feed',
callback_type = 'interface'),
PushButton('ref resh',
text = 'Refresh All',
callback = 'refresh_feeds' ,
callback_type = 'interface'),
PushButton('del ete',
text = 'Delete Feed',
callback = 'delete_feed',
callback_type = 'interface'),
TreeView('tree' ,
visible_min_wid th = ('character', 84),
visible_min_hei ght = ('character', 40),
action_callback = 'browse_item',
callback_type = 'item_interface ',
expandp_functio n = lambda: True, # not sure how best to translate
children_functi on = 'tree_item_chil dren',
print_function = 'tree_item_stri ng')
],
layouts = [
ColumnLayout('m ain', ('top', 'tree')),
RowLayout('top' , ('url_pane', 'add', 'refresh', 'delete'))
],
title = 'Barebones RSS Reader v1.0')
self.channels = [
parse_rss_from_ url(url) for url in [
'http://planet.lisp.org/rss20.xml',
'http://feeds.theonion. com/theonion/daily']]

def add_feed(self):
...

def delete_feed(sel f):
...

# etc.

--
Greg

[Jon Harrop]

Rob Thorpe wrote:

Once you can do the above then you can phrase programs entirely in
terms of composition of functions, which is what functional programming
is about.

There are many aspects to functional programming. Some languages (like Lisp
and Python) are very impure and hardly encourage functional programming.
Other languages (like OCaml, SML, F# and Scheme) are impure but make
functional programming easy (e.g. higher-order functions, currying,
continuation passing style are all concise and statically checked). Some
languages (like Haskell) are purely functional, so everything must be
immutable.

Getting good performance though is problematic without being able to
evaluate parts at compile time. This is why almost all functional
languages provide that feature in some form.

Actually the languages that don't provide compile-time execution (OCaml, SML
and F#) are typically much faster than those that do (Lisp, Scheme, Dylan).

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet

[Anders J. Munch]

jayessay wrote:

Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.

Really? So how do you write a portable program in CL, that is to run
for unbounded lengths of time?

- Anders

[Rob Thorpe]

Anders J. Munch wrote:

jayessay wrote:

Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.

Really? So how do you write a portable program in CL, that is to run
for unbounded lengths of time?

You can't.

The thing about the spec not defining GC is almost a bit of humour.
No-one would use an implementation with no GC.

The issue with specifying it is: How would you do it? The memory used
by a program is an aspect of the language implementation and the system
the program is running on, so how can it be defined in a useful way?

You could say for example "Storage allocated for an object is released
when the object is no longer visible and memory usage is high". But
how do you define how high memory usage should be? You could say when
memory is almost exhausted, even that is difficult to define. Then you
could have the situation where someone creates a lisp compiler than
emits FPGA netlists, how do you check something like this?

None of this would be in the spirit of the spec, which doesn't even
define memory AFAIK. The spec deals entirely in matters of the
language and it's appearance to the programmer. For what it's worth I
think the C spec is the same, and says nothing about actual memory
usage.

[josephoswaldgg]

Anders J. Munch wrote:

jayessay wrote:

Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.

Really? So how do you write a portable program in CL, that is to run
for unbounded lengths of time?

- Anders

Write it, and depend on the implementation to do its job well, and
complain to the implementors if it doesn't.

How do you write a portable program in C that is to run for unbounded
lengths of time? Even if you religiously call free() on every
malloc()'d block, you could eventually fragment memory enough that the
allocator might eventually fail. You can exceed the VM capacity. The OS
could decide to crash periodically. The power supply could fail, the
sun could progress to the red giant phase...

The real answer is that these are not issues for the language
definition, but for the implementor.

[Pascal Bourguignon]

"Rob Thorpe" <rt*****@realwo rldtech.comwrit es:

Anders J. Munch wrote:

>jayessay wrote:

> Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.

Really? So how do you write a portable program in CL, that is to run
for unbounded lengths of time?

You can't.

You can. Just use reversible operations.

Or use pre-allocated objects. Yes, that means that you implement your
own memory management or garbage collector, but this would be portable.

--
__Pascal Bourguignon__ http://www.informatimago.com/

"Do not adjust your mind, there is a fault in reality"
-- on a wall many years ago in Oxford.

[Rob Thorpe]

Pascal Bourguignon wrote:

"Rob Thorpe" <rt*****@realwo rldtech.comwrit es:

Anders J. Munch wrote:

jayessay wrote:
Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.

Really? So how do you write a portable program in CL, that is to run
for unbounded lengths of time?

You can't.

You can. Just use reversible operations.

Or use pre-allocated objects. Yes, that means that you implement your
own memory management or garbage collector, but this would be portable.

I don't think there is any gaurantee in the spec that says that even
doing nothing at all doesn't allocate more memory. AFAIK a conforming
implementation could leak a fixed amount of memory per second.

[Anders J. Munch]

Rob Thorpe wrote:

Anders J. Munch wrote:

>Really? So how do you write a portable program in CL, that is to
run for unbounded lengths of time?

You can't.

The thing about the spec not defining GC is almost a bit of humour.
No-one would use an implementation with no GC.

The issue with specifying it is: How would you do it? The memory
used by a program is an aspect of the language implementation and
the system the program is running on, so how can it be defined in a
useful way?

Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.

Require that u(t) is a member of O(t -max{t'<=t: r(t')})

There. That wasn't so hard, was it?

- Anders

[Rob Thorpe]

Anders J. Munch wrote:

Rob Thorpe wrote:

Anders J. Munch wrote:

>Really? So how do you write a portable program in CL, that is to
>run for unbounded lengths of time?

>
You can't.
>
The thing about the spec not defining GC is almost a bit of humour.
No-one would use an implementation with no GC.
>
The issue with specifying it is: How would you do it? The memory
used by a program is an aspect of the language implementation and
the system the program is running on, so how can it be defined in a
useful way?

Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.

Require that u(t) is a member of O(t -max{t'<=t: r(t')})

There. That wasn't so hard, was it?

That's quite a clever definition actually.
But, let's say I have a lisp machine. It has an unusual architecture,
it's made entirely of SRAM cells of ~9bits. Sometimes these cells are
used as storage, sometimes their contents represent logic circuits and
the routing between them is configured to form them into a processor.
Please tell me what reachable memory is ;). (The above processor is
not science fiction, it could easily be done with FPGAs)

I suppose a solution would be:-

If the lisp implementation runs on a fixed processor that has separate
storage then ...

Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.
....