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

[Paul Rubin]

Jon Harrop <jo*@ffconsulta ncy.comwrites:

# cond 2
[( = ) 1, "one";
( = ) 2, "two";
( = ) 3, "three"]
"neither one, two nor three";;
- : string = "two"

I'm missing something. Doesn't Ocaml have strict evaluation? That
means if you use function calls instead of string constants in those
values, they all get called. You haven't really done what cond does.

[Kay Schluehr]

George Sakkis schrieb:

Well, for one thing we never held the first place anyway. Second, what
appears to be the big boost for Ruby today maybe its death sentence
tomorrow, ending up as a niche language for web apps, like PHP today.
With a large crowd undoubtly, but I bet most Pythonistas would prefer
lower popularity than ending up in a corner of the application
spectrum.

Who really wants to write web apps? Web apps are just an excuse for
Pythonistas to write web frameworks.

[Paul Rubin]

Jon Harrop <jo*@ffconsulta ncy.comwrites:

Nothing stops you from re-using the same internal function name in
your Python code, like you might use "i" as a throwaway loop index in
several places in the same function. It's just like in Scheme...

It is not "just like in Scheme" if you don't have anonymous functions in
Python.

Python has anonymous functions (what they can do is somewhat limited
by syntax) but the similarity mentioned with Scheme was about the data
objects. Anyway you don't need to pollute the namespace with lots of
(i.e. more than one) different temporary function name even if you use
non-anonymous functions.

[Paul Rubin]

"Kay Schluehr" <ka**********@g mx.netwrites:

A few months ago, I missed the Condition System most
when using Python, and also lexical scope. However, it is nice to work
with friends, who know Python and not Lisp.)

Could you explain in which way Python lacks lexical scoping?

Python has lexical scope but you can't update lexical variables from
scopes other than the innermost or outermost (global) scope. I.e:

def counter():
x = 0
def g():
x += 1
return x
return g

c = counter()
print c()

doesn't do what you'd hope. Yes there are workarounds but they're not
all that satisfactory.

[Paul Rubin]

"Wolfram Fenske" <in***@gmx.netw rites:

Yes, I wrote about it in another post. It was introduced in Python
2.5. And if it hadn't been I'd still have to write code like this.

You could do something with decorators that's not too bad. You'd end
up writing:

@withConnection
def some_func():
do_whatever_stu ff ()

[Paul Rubin]

Jon Harrop <jo*@ffconsulta ncy.comwrites:

I discovered this recently with F#. Although F# (as a dialect of OCaml) is
impure like Lisp, it does make purely functional programming easy and
provides many purely functional data structures. I translated 15kLOC of
mostly-functional OCaml code into F# and only had to add four locks to make
the whole library concurrent.

The idea of the composable-STM stuff is to not add locks at all, just
mark sections as atomic and the right stuff happens automagically
(i.e. you never have to worry about deadlock), including when you nest
such sections. Its performance also exceeds traditional locking. But
it relies on Haskell's purity.

[Jon Harrop]

Paul Rubin wrote:

Jon Harrop <jo*@ffconsulta ncy.comwrites:

># cond 2
[( = ) 1, "one";
( = ) 2, "two";
( = ) 3, "three"]
"neither one, two nor three";;
- : string = "two"

I'm missing something. Doesn't Ocaml have strict evaluation?

Yes.

That means if you use function calls instead of string constants in those
values, they all get called.

True.

You haven't really done what cond does.

Good point. How about this:

# let rec cond x rules default = match rules with
| [] -default
| f :: t -match f x with
| Some e -e
| None -cond x t default;;
val cond : 'a -('a -'b option) list -'b -'b = <fun>

# cond 2
[(fun n -if n=1 then Some "one" else None);
(fun n -if n=2 then Some "two" else None);
(fun n -if n=3 then Some "three" else None)]
"neither one, two nor three";;
- : string = "two"

The 'Some "one"' is only called if its predicate matched. Anyway, you don't
need macros to write COND and you don't need COND if you have pattern
matching.

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

[Jon Harrop]

Paul Rubin wrote:

Jon Harrop <jo*@ffconsulta ncy.comwrites:

>I discovered this recently with F#. Although F# (as a dialect of OCaml)
is impure like Lisp, it does make purely functional programming easy and
provides many purely functional data structures. I translated 15kLOC of
mostly-functional OCaml code into F# and only had to add four locks to
make the whole library concurrent.

The idea of the composable-STM stuff is to not add locks at all, just
mark sections as atomic and the right stuff happens automagically
(i.e. you never have to worry about deadlock), including when you nest
such sections. Its performance also exceeds traditional locking. But
it relies on Haskell's purity.

Yes. My point is that I only had to add four locks in 15kLOC of F# code
because my code was almost entirely pure. So F# is a long way towards that
Haskell ideal whilst having many other advantages over Haskell, like
predictable memory usage.

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

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 00:01:34 -0800))
(

PRI'm not persuaded, I haven't examined his example carefully yet but it
PRlooks like basically a reader hack. Lexical scope in Lisp means among
PRother things lexical closures and (maybe I'm mistaken) it seemed to me
PRAlex's example didn't supply that.

lexical scope is pretty low-level concept that affects lot of stuff, so it
requires lot of changes -- we are not extending a language, but build a new
one actually.
we'll have to create object 'lexical environment' and to query it for
variable values instead of just using variable values: var -(query env
'var).
then, we'll need to make closures -- that is a pair of environment and code
itself.
so, it's very close to writting new interpreter -- but it's order of
magnitude easier to write this interpreter via macros than from scratch,
most other language constructs can be reused.
that's the point -- macros allow to implement a language with aprox. same
syntax but different semantics relatively easily.

PR I'm also unconvinced (so far) of his description of call/cc as a Lisp
PRmacro but that's going to take me some head scratching.

there is a chapter about continuations in Paul Graham's "On Lisp".

"Common Lisp doesn't provide call/cc, but with a little extra effort we can
do the same things as we can in Scheme. This section shows how to use macros
to build continuations in Common Lisp programs."

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")

[Paul Rubin]

Jon Harrop <jo*@ffconsulta ncy.comwrites:

Yes. My point is that I only had to add four locks in 15kLOC of F# code
because my code was almost entirely pure.

But that's like saying you only had to call malloc in 4 different
places, which means dealing with freeing, buffer overruns, etc. As
soon as you use any locks at all, you're susceptable to all the
headaches of dealing with locks. Anyway this is turning into
ML vs. Haskell, maybe an improvement on Lisp vs. Python but still OT.

So F# is a long way towards that Haskell ideal whilst having many
other advantages over Haskell, like predictable memory usage.

F# is pretty similar to ML, right? Hmm. Haskell's memory usage
issues stem more from laziness than purity. One could imagine a
strict Haskell dialect that was still pure (I think ML is heading
in that direction) but that would throw out a lot of Haskell coolness.

Does OCaml support parallel threads at all? I mean using multiple
cpu's simultaneously. I thought it didn't and this was one of the
factors that got me to make the leap into Haskell.