BIG successes of Lisp (was ...)

[Donn Cave]

Which leads us back to having to manually close files.

I DON'T want to manually close files. I DON'T want to deal with the
limitations of with-open-file. And, here's the important bit, I DON'T WANT
TO COMBINE OR CHOOSE BETWEEN THESE TWO METHODS, BOTH OF WHICH ARE FLAWED.

What I want to open a file and have it close automatically when I am done
with it. I can do that in C++. Why can't I do it in Python?

None of the above makes a whole lot of sense to me, and judging
by the use of upper case I'm inclined to believe that discussing
this with comp.lang.lisp participants has caused you to become
disturbed. I am accordingly posting this only to comp.lang.python.

You can have files close automatically in Python, but automatically
isn't by itself a rather vacuous term, and `when I am done with it'
doesn't help a bit. In C Python, when a file object is no longer
referenced by any part of the program, it closes. If it's local
to a function, including bound only to a function parameter or some
such thing, that will occur when control returns from the function.

Unless the file becomes involved in a circular reference, in which
case the close will be deferred until the references are discovered
and broken by the garbage collector. Unless the garbage collector
is unable to do so because of some property of the members, such as
a __del__ method.

No doubt there is a great deal of C++ arcana that I have missed out
on, but the basic finalization issues are the same as far as I know.
C++ programmers aren't subject to the above exceptions only because
they don't get any of the functionality to which these are exceptions!
Function local objects are always deleted on return from the function
regardless - and any other part of the program that retains a pointer
to such an object will become unsound. Objects allocated on the heap
have to be deleted explicitly, after which other parts of the program
that reference them will become unsound. If you do a fraction of the
explicit management that C++ requires, you can get reliable finalization.

I am not familiar with with-open-file, but I imagine if you decide to
write your software in Lisp, you will probably want to give it a try.

There is also nothing wrong with closing a file explicitly. There are
reasons for it that have nothing to do with the language, and then there
is a school of thought (actually the party line for Python) that says
you should explicitly close files in any case because the memory
management rules are different for Java Python and could in theory
change in a later release of C Python. Apparently Java's finalization
is not immediate.

Donn Cave, (e-mail address removed)

 

[Rainer Deyke]

In C++ you must choose between a local variable for the stream (which
is equivalent to with-open-file) or dynamically allocated object
(which is equivalent to open & close, where close is spelled delete).

I can also choose to have the stream reference counted (through
boost::shared_ptr or similar), and I can make it a member variable of an
object (tying the lifetime of the stream to the lifetime of the owning
object).

Now, I *could* write my own reference counting stream wrapper in Python,
together with a with_reference_to_stream HOF. I could, but it would be
expensive, not only in terms of performnace, but also in terms of syntax and
mental overhead.

You can't say that you want the C++ way and you don't want explicit
open & close and with-open-file, because they are equivalent! They
differ only in syntax details, but the style of usage and limitations
are the same.

The syntax is actually very significant here. Python's lack of anonymous
code blocks hurts, but even without this, the C++ syntax is more lightweight
and therefore more managable. Compare the levels of indentation:

void f()
{
std::fstream a("a"), b("b");
do_something(a, b);
std::fstream c;
do_something_else(a, b, c);
}

def f():
with_open_file(a = open("a")):
with_open_file(b = open("b")):
do_something(a, b)
with_open_file(c = open("c")):
do_something_else(a, b, c)

 

[Rainer Deyke]

2. But the computer shouldn't wait until it can prove you are done
to close the file.

Wrong. The computer can prove that I am done with the file the moment my
last reference to the file is gone. I demand nothing more (or less).

 

[Rainer Deyke]

You can have files close automatically in Python, but automatically
isn't by itself a rather vacuous term, and `when I am done with it'
doesn't help a bit. In C Python, when a file object is no longer
referenced by any part of the program, it closes. If it's local
to a function, including bound only to a function parameter or some
such thing, that will occur when control returns from the function.

I understand both the specification and the implementation of finalization
in Python, as well as the reasoning behind them. My point is, I would
prefer it if Python guaranteed immediate finalization of unreferenced
objects. Maybe I'll write a PEP about if someday.

 

[Kaz Kylheku]

Kaz Kylheku:

We have decidedly different definitions of what a "domain-specific
language" means. To you it means the semantics expressed as
an s-exp. To me it means the syntax is also domain specific. Eg,
Python is a domain specific language where the domain is
"languages where people complain about scope defined by
whitespace."

There are two levels of syntax: the read syntax, and a deeper abstract
syntax. People who understand only the first one to be syntax are
scared of syntactic manipulation, because they are used to being
burned by syntax: stupid precedence rules, quirky punctuation,
semicolon diseases, strange whitespace handling, and so on.

A symbolic expression is a printed form which codes for a data
structure. That data structure continues to exhibit syntax, long after
the parentheses, whitespace and other lexical elements are processed
and gone.

Yes, one can support Python in Lisp as a reader macro -- but
it isn't done because Lispers would just write the Python out
as an S-exp.

They would do that in cases when they have to invoke so many escape
hatches to embed Lisp code in the Python that the read syntax no
longer provides any benefit.

But then it wouldn't be Python, because the domain
language *includes*domain*syntax*.

In other words, writing the domain language as an S-exp
is a short cut to make it easier on the programmer, and not
on the domain specialist.

Writing the language in terms of a data structure (which can be
converted back and forth to a printed symbolic expression) is not a
shortcut; it's proper layering at work. The read syntax can be
independently developed; the symbolic expressions merely give you a
generic one for free! Read syntax is just lexical sugar. It can be
quite important. Heck symbolic expressions have enough of it; it would
be a pain to type (QUOTE X) all the time instead of 'X, or
#.(make-array '(4) :element-type 'bit :initial-contents '(1 1 0 1))
instead of #*1101!

Did you look at my example doing just that? I built
an AST for Python and converted it into a normal function.

I'm looking for a Python example which adds a new kind of statement to
the language, and then later in the source file uses that statement to
write a part of the program, such that it's all processed in the same
pass. The statement can be nested in existing ones, and can have
existing syntax embedded in it. Oh yeah, and it should work on at
least two Python implementations.

There isn't. But then there isn't need. The question isn't

When you start talking about need, that quickly becomes a losing
proposition. Because needs are actually wants in disguise. Do human
beings need electricity, running water or food prepared by heating?

"how do I do this construct that I expect in Lisp?" it's "how
do I solve this problem?"

The answer is: if I can get Lisp, I use that. Otherwise I work around
that. If you are in the middle of civilization, and the question is
``what's for dinner'', the answers are to go to the supermarket or a
restaurant. If you are lost in the woods, then you have to reason
differently.

There are other ways to solve
that problem than creating a "parse tree template" and to
date there have been few cases where the alternatives were
significantly worse -- even in the case of translating a domain

What cases? Where? Can you be more specific? Can ``significantly
worse'' be put into some kind of numbers?

language into local syntax, which is a Lisp specialty, it's only
about twice as long for Python as for Lisp and definitely
not "impossible" like you claimed.

Okay, I'm expecting that example I asked for to be only twice as long
as the Lisp version.

 

[prunesquallor]

Wrong. The computer can prove that I am done with the file the moment my
last reference to the file is gone. I demand nothing more (or less).

If you don't care about performance, this is trivial.

 

[Bjorn Pettersen]

(e-mail address removed) (Thomas F. Burdick) wrote in

I hope you put assertion in your code so that it won't run under
Jython, because that's the kind of insidious bug that would be
*aweful* to find the hard way.

I'm assuming the "import win32con" etc., will do Seriously, this
would be a minor issue compared with everything else I want to connect
to (e.g. 950KLocs of legacy c++ -- somehow I don't think I'd get the go-

(I really don't understand why you wouldn't just want at least real
closures, so you can just use call_with_open_file, and not have to
worry about what GC you're using when *opening* *files*)

I'm not the one worrying here <wink>. I know exactly what Python does
and it is no cognitive burden. How would you rewrite these without
obfuscating the real work with book-keeping tasks, or leaving the file
open longer than necessary?

timestamp = datetime.now().strftime('%Y%m%d%H%M%S\n')
file('log', 'a').write(timestamp)

file('output', 'w').write(file('template').read() % locals())

nwords = sum([len(line.split()) for line in file('input')])

for line in file('input'):
print line[:79]

-- bjorn

 

[Donn Cave]

Quoth "Rainer Deyke" <[email protected]>:
....
| I understand both the specification and the implementation of finalization
| in Python, as well as the reasoning behind them. My point is, I would
| prefer it if Python guaranteed immediate finalization of unreferenced
| objects. Maybe I'll write a PEP about if someday.

Write code first! I think most would see it as a good thing,
but I have the impression from somewhere that a guarantee of
immediate finalization might not be a practical possibility,
given reference cycles etc. Between that and the fact that the
present situation is close enough that few people care about the
difference, an implementation would really help your cause.

Donn Cave, (e-mail address removed)

 

[Nikodemus Siivola]

I'm not the one worrying here <wink>. I know exactly what Python does
and it is no cognitive burden.

"To foil the maintenance engineer, you must understand how he thinks."

Cheers,

-- Nikodemus

 

[Stephen Horne]

If we had the same perceptions about reality as our ancestors, we
wouldn't reproduce very successfully now, because the world has
changed as a result of their reproductive success.

Except for the fact that (1) people, at least those with power,
changed the world to suit themselves, and (2) the things that really
count for perception haven't changed - objects are still objects and
still follow the same laws of physics, for instance, even if there are
occasional novel touches such as some of those objects having engines.

 

[Stephen Horne]

.....
It is a commonplace of developmental psychology that the persistence of
objects is learned by children at some relatively young age (normally 3
months as I recall). I assume that children learn the persistence of
hidden objects by some statistical mechanism ie if it happens often
enough it must be true (setting up enough neural connections etc).

Would the reality of children subjected to a world where hidden objects
were somehow randomly 'disappeared' be more or less objective then that
of normal children.

Unlucky experimental cats brought up in vertical stripe worlds were
completely unable to perceive horizontals so their later reality was
apparently filled with invisible and mysterious objects. I can't
remember if they could do better by rotating their heads, but even that
would be quite weird.

I think it unwise to make strong statements about reality when we know
so little about it. Apparently now the universe is 90-95% stuff we don't
know anything about and we only found that out in the last 10 years.

Actually, a great deal is understood about precisely that mechanism
you describe. There is nothing mysterious about it. Even innate
processes depend of certain features of the environment which
evolution has effectively assumed constant, such as - for the cats
example above - the presence of various angles of rough lines in the
environment. If these features do not occur at the correct
developmental stage, the processes that wire the appropriate neurons
together simply don't occur. Evolution is nothing if not pragmatic.

As for children subjected to a world where hidden objects suddenly
disappeared, you may be surprised. I am not aware of anyone doing that
precise experiment for obvious moral reasons, but if you know where to
look you can find evidence...

The human brain continues developing after birth. It cannot be fully
developed at birth, as with most animals, because of the limits of the
human female hip bone. Continued brain developement after birth does
NOT automatically mean learning, therefore.

Take for instance social development. Human cruelty knowing no bounds,
there have been children who were shut away from all human interaction
by their parents. These children do *not* become autistic - even when
found well into their teenage years, and despite the symptoms of
traumatic stress, such children socialise remarkably well and
extremely quickly - far faster than they learn language, for instance
- whereas an autistic may never learn good socialisation despite a
lifetime of intense effort (I speak from experience).

Reason - a substantial part of socialisation is innate (and thus
accessible without learning), but neurological damage prevents that
innate socialisation ability from developing.

Even if this was not the case, you have not proved that reality is not
real. Of course perception still varies slightly from person to
person, and more extensively from species to species, but it is not
independent of reality - it still has to be tied to reality as closely
as possible or else it is useless.

 

[Robin Becker]

Even if this was not the case, you have not proved that reality is not
real. Of course perception still varies slightly from person to
person, and more extensively from species to species, but it is not
independent of reality - it still has to be tied to reality as closely
as possible or else it is useless.

Actually it was not my intention to attempt any such proof, merely to
indicate that what we call real is at the mercy of perception. If I
choose to call a particular consensus version of reality the 'one true
reality' I'm almost certainly wrong. As with most of current physics we
understand that 'reality' is a model. An evolution based on low speed
physics hardly prepares us for quantum mechanics and spooky action at a
distance interactions. For that reality, which we cannot perceive, we
employ mathematicians as interpreters (priests?) to argue about the
number of hidden dimensions etc etc. Even causality is frowned upon in
some circles.

What we humans call 'reality' is completely determined by our senses and
the instruments we can build. How we interpret the data is powerfully
influenced by our social environment and history. As an example the
persistence of material objects is alleged by some to be true only for
small time scales <10^31 years; humans don't have long enough to learn
that.

 

[Drazen Gemic]

Python doesn't try (too) hard to change the ordinary manner of thinking,

just to be as transparent as possible. I guess in that sense it encourages a
degree of mental sloth, but the objective is executable pseudocode. Lisp

I have started with Python because I needed a fast way to develop
solutions using OO. Python fullfiled my expectations.

The point is that I have started with Python because I was missing
something, not because I wanted to expand my knowledge.

Learning one programming language is a burden, because there is always to
little time for everything.

Lisp is probably cool, but what will I gain from Lisp ? What will
justify my investment, I mean spent time ?

DG

 

[Stephen Horne]

Actually it was not my intention to attempt any such proof, merely to
indicate that what we call real is at the mercy of perception. If I
choose to call a particular consensus version of reality the 'one true
reality' I'm almost certainly wrong.

True. But perception cannot change reality. Reality is not about
perception - it existed long before there was anything capable of
percieving.

What we *normally* call real is normally a perception, or more
precisely (as you say) a model, and not the actual reality. But at
least when that model has been built up from experimental evidence, it
is vanishingly unlikely to have approached anything other than
reality. The model defined by science has limits and inaccuracies of
course, but it is not credible to claim that it is arbitrary.

What we humans call 'reality' is completely determined by our senses and
the instruments we can build.

Not at all. What our senses and instuments are observing is real,
*not* arbitrary, and *not* affected by perception. Our perceptions are
dependent on reality, even though they cannot be a perfect. We are not
free to define perception arbitrarily precisely because it is a
representation of reality, derived from the information provided by
our senses.

As I already mentioned, if a primitive person observes a car and
theorises that there is a demon under the hood, that does not become
true. Reality does not care about anyones perceptions as it is not
dependent on them in any way - perceptions are functionally dependent
on reality, and our perceptions are designed to form a useful model of
reality.

If there was no reality, there would be no common baseline for our
perceptions and therefore no reason for any commonality between them.
In fact there would be no reason to have perceptions at all.

 

[Robin Becker]

As I already mentioned, if a primitive person observes a car and
theorises that there is a demon under the hood, that does not become
true. Reality does not care about anyones perceptions as it is not
dependent on them in any way - perceptions are functionally dependent
on reality, and our perceptions are designed to form a useful model of
reality.

We observe electrons and make up mathematical theories etc etc, but in
reality little demons are driving them around.

Your assertion that there is an objective reality requires proof as
well. Probably it cannot be proved, but must be made an axiom. The
scientific method requires falsifiability.

The fact is we cannot perceive well enough to determine reality. The
physicists say that observation alters the result so if Heisenberg is
right there is no absolute reality. Perhaps by wishing hard I can get my
batteries to last longer 1 time in 10^67.

Awareness certainly mucks things up in socio-economic systems which are
also real in some sense. I hear people putting forward the view that
time is a construct of our minds; does time flow?

This is a bit too meta-physical, but then much of modern physics is like
that. Since much of physics is done by counting events we are in the
position of the man who having jumped out of the top floor observes that
all's well after falling past the third floor as falling past floors
10,9,... etc didn't hurt. We cannot exclude exceptional events.

 

[Bjorn Pettersen]

Quoth "Rainer Deyke" <[email protected]>:
...
| I understand both the specification and the implementation of
| finalization in Python, as well as the reasoning behind them. My
| point is, I would prefer it if Python guaranteed immediate
| finalization of unreferenced objects. Maybe I'll write a PEP about
| if someday.

Write code first! I think most would see it as a good thing,
but I have the impression from somewhere that a guarantee of
immediate finalization might not be a practical possibility,
given reference cycles etc.

google for 'tofte talpin region analysis'.

-- bjorn

 

[Alex Martelli]

Stephen Horne wrote:
...

True. But perception cannot change reality. Reality is not about
perception - it existed long before there was anything capable of
percieving.

You are so WONDERFULLY certain about such things -- including the
fact that "before" is crucial, i.e., the arrow of time has some
intrinsic meaning.

Physicist J. A. Wheeler (and his peer referees for the "IBM Journal
of Research and Development") didn't have your admirable certainty
that "reality is not about perception".

Which is why in "World as system self-synthesized by quantum networking",
see the summary and pointer for PDF download at (long URL):
http://domino.watson.ibm.com/tchjr/journalindex.nsf/0/6a79d8a9b2068e4e85256bfa0067f6dd?OpenDocument
Wheeler seriously considered the hypothesis of...:
"""
an all- encompassing role for observer-participancy: to build, in time to
come, no minor part of what we call its past ? our past, present, and
future ? but this whole vast world.
"""

"observer-participancy" is a delightful way to say "perception", of
course, but the most interesting part of this is that, to a theoretical-
enough physicist, the mere fact that something happens in the future is
obviously no bar to that something "building" something else in the past.

Now, it IS quite possible, of course, that Wheeler's working hypothesis
that "the world is a self-synthesizing system of existences, built on
observer-participancy" will one day turn out to be unfounded -- once
somebody's gone to the trouble of developing it out completely in fully
predictive form, devise suitable experiments, and monitor results.

But to dismiss the hypothesis out of hand, "just because", does not
seem to me to be a productive stance. That the universe cannot have
built its own past through future acts of perception by existences
within the universe is "obvious"... but so, in the recent past, were
SO many other things, that just didn't turn out to hold....


Of course, theoretical-enough physicists do such things just to annoy
us feet-firm-on-ground, no-nonsense types. However, there are
other, less-weird approaches, totally orthogonal to ones such as
Wheeler's. I would particularly recommend:

The Social Construction of Reality: A Treatise in the Sociology of Knowledge
by Peter L. Berger, Thomas Luckmann
ISBN: 0385058985

it's dated (late '60s), but I think it's still an important text for
the layman who's actually interested in the sociology of knowledge
(if experts can recommend more updated texts suitable for laymen I'll
be grateful -- NB: deconstructionists need not apply. I know John
Searle has written a book with a curiously similar title, "The
Construction of Social Reality", and takes hundreds of pages to defend
the view that there ARE "brute facts" independent of human actions
and perceptions -- but does NOT deny the existence of "social reality"
superimposed, so to speak, upon "brute reality". But that's all I know
about this book -- a capsule summary -- and I'm not as interested in
digging much deeper about contemporary philosophy, as I am about such
disciplines as sociology.

Looking on the web for the ISBN I hit upon several google links that
look interesting (no time to pursue them in depth, sorry), such as

http://www.virtualschool.edu/mon/SocialConstruction/

But, I'm sure y'all are googlers just as good as I am.


Alex

 

[Tayss]

Incidentally, I have never seen--and expect never to see--some new
mysterious domain where Python is too limited because the designers did
not forsee the problem area. Nor similarly with other very high level
languages. It NEVER happens that you just cannot solve a problem
because of the lack of some novel syntax to do so... that's what
libraries are for.

The problem I have with this argument is, people already invent little
"languages" whenever they create new libraries. Right now I'm working
with wxPython. Here's an idiom that comes up (you don't need to
understand it):

app = wxPySimpleApp()
frame = MainWindow(None, -1, "A window")
frame.Show(True)
app.MainLoop()

Here, I have to put each line in a magical order. Deviate the
slightest bit, the thing crashes hard. It is hard to work with this
order; wxPython inherited an old design (not wxPython's fault), and
it's showing its age.

I'd fix it, but functions don't give me that power. I need to specify
the order of execution, because GUIs are all about side-effects --
macros are a solution worth having in your belt.

I am chained to wxPython's language. It's a language that is
basically Python-in-a-weird-order. Why not accept we need good
abstraction facilities because code has a habit of spiralling into
unmaintainability?

I'm not slamming Python or wxPython, since for this project they're
objectively better than today's CL. My only point is macros shouldn't
be underestimated. Especially since there are lots of things built
into lisp to make macros nice to use. (Like the macroexpand function,
which shows you what macros turn into.) Even if macros are
objectively wrong for Python, people should still know about them.

 

[Marcin 'Qrczak' Kowalczyk]

app = wxPySimpleApp()
frame = MainWindow(None, -1, "A window")
frame.Show(True)
app.MainLoop()

Here, I have to put each line in a magical order. Deviate the
slightest bit, the thing crashes hard. It is hard to work with this
order; wxPython inherited an old design (not wxPython's fault), and
it's showing its age.

I'd fix it, but functions don't give me that power.
Why?

I need to specify the order of execution,

What's the problem in specifying the order of execution in functions?

 

[Anton Vredegoor]

What we humans call 'reality' is completely determined by our senses and
the instruments we can build. How we interpret the data is powerfully
influenced by our social environment and history. As an example the
persistence of material objects is alleged by some to be true only for
small time scales <10^31 years; humans don't have long enough to learn
that.

Persistence of material objects will become obsolete much sooner. See:

http://crnano.org/systems.htm

This discusses three ethical systems and their usefulness for dealing
with the coming nanotechnology era.

The articles conclusion has quite a Pythonic ring to it, I feel.
However just like Python, it will have to give up on backward
compatibility someday

Anton