Python syntax in Lisp and Scheme

[Pascal Costanza]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)

Stephen Horne wrote:
[color=blue]
> This would make some sense. After all, 'head' and 'tail' actually
> imply some things that are not always true. Those 'cons' thingies may
> be trees rather than lists, and even if they are lists they could be
> backwards (most of the items under the 'car' side with only one item
> on the 'cdr' side) which is certainly not what I'd expect from 'head'
> and 'tail'.[/color]

I think that's the essential point here. The advantage of the names car
and cdr is that they _don't_ mean anything specific. I wouldn't mind if
they were called jrl and jol, or rgk and rsk, etc. pp.

This is similar to how array elements are accessed. In expressions like
a[5], the number 5 doesn't mean anything specific either.


Pascal

--
Pascal Costanza University of Bonn
mailto:costanza @web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

[Paul Foley]

Re: Python syntax in Lisp and Scheme

On Tue, 14 Oct 2003 01:26:54 -0400, David Mertz wrote:
[color=blue]
> Matthew Danish <mdanish@andrew .cmu.edu> wrote previously:
> |On Wed, Oct 08, 2003 at 03:59:19PM -0400, David Mertz wrote:
> |> |Come on. Haskell has a nice type system. Python is an application of
> |> |Greespun's Tenth Rule of programming.
> |> Btw. This is more nonsense. HOFs are not a special Lisp thing. Haskell
> |> does them much better, for example... and so does Python.[/color]
[color=blue]
> |Wow. The language with the limited lambda form, whose Creator regrets
> |including in the language, is ... better ... at HOFs?
> |You must be smoking something really good.[/color]
[color=blue]
> I guess a much better saying than Greenspun's would be something like:
> "Those who know only Lisp are doomed to repeat it (whenver they look at
> another language)." It does a better job of getting at the actual
> dynamic.[/color]

Is there anyone who knows only Lisp?

Those who know Lisp repeat it for a reason -- and it isn't because
it's all they know! [Besides, Greenspun's 10th isn't about _Lispers_
reinventing Lisp; it's about _everybody else_ reinventing Lisp]
[color=blue]
> In point of fact, Python could completely eliminate the operator
> 'lambda', and remain exactly as useful for HOFs. Some Pythonistas seem
> to want this, and it might well happen in Python3000. It makes no
> difference... the alpha and omega of HOFs is that functions are first
> class objects that can be passed and returned. Whether they happen to
> have names is utterly irrelevant, anonymity is nothing special.[/color]

True enough. Naming things is a pain though. Imagine if you couldn't
use numbers without naming them: e.g., if instead of 2 + 3 you had to
do something like

two = 2
three = 3
two + three

Bleargh! It "makes no difference" in much the same way that using
assembler instead of Python "makes no difference" -- you can do the
same thing either one, but one way is enormously more painful.

[Mind you, Python's lambda is next to useless anyway]

--
Cogito ergo I'm right and you're wrong. -- Blair Houghton

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz> "))

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

(I know, I swore off cross-posting on this topic, but the claims
made here were too outrageous for me to ignore)

<prunesquallor@ comcast.net>[color=blue]
> I wish to show that local information is insufficient for cutting and
> pasting under some circumstances.[/color]

Absolutely correct, but rarely the source of errors. When it does
occur it is almost always immediately after the cut&paste and so
the context is fresh in the mind of the who did the c&p. The chance
for it to appear in wild code is minute. I can't recall ever coming
across it.
[color=blue]
> Consider this thought experiment: pick a character (like parenthesis
> for example) go to a random line in a lisp file and insert four of them.
> Is the result syntactically correct? No.[/color]

You're surely exaggerating here. Here's your factorial example,
which has not been cleaned up.

(defun factorial (x)
(if (> x 0)
x
(*
(factorial (- x 1))
x
)))

I'll insert four "a" characters in the function name

(defun aaaafactorial (x)
(if (> x 0)
x
(*
(factorial (- x 1))
x
)))

Is that not syntactically correct? For that matter, what if
I insert four spaces, like

(defun factorial (x)
(if (> x 0)
x
(*
(fact orial (- x 1))
x
)))

or insert four quotes

(defun factorial (x)
(if (> x 0)
x
''''(*
(factorial (- x 1))
x
)))

[color=blue]
> However, there is a class of *syntactic* error that is possible in
> python, but is not possible in lisp[/color]

Here's a class of error possible in Lisp and extremely hard to get
in Python -- omitting a space between an operator and an operand
causes an error

Valid Lisp: (- x 1)
Invalid Lisp: (-x 1) ; ;well, not invalid but semantically different

Valid Python: x - 1
Valid Python: x-1

Yes, I know, it's because '-x' isn't an operator. Tell it to the
beginning programmer who would have these problems in Python.

Here's another class of error you can get in Lisp but is hard to
get in Python (except in a string). Randomly insert a '

Valid Lisp: (- x 1)
Valid Lisp: '(- x 1) ;;; but semantically very different

Will the same beginning user you talk about for Python be
able to identify a single randomly inserted quote in Lisp?
[color=blue]
> Now go to a random line in a python file and insert four spaces. Is
> the result syntactically correct? Likely. Could a naive user find
> them? Unlikely. Could you write a program to find them? No.[/color]

I tried writing code to test this automatically but ran into problems
because I inserting four spaces at the start of a line may be syntactically
correct and may also not affect the semantics. For example

def spam(x = some_value,
y = some_other_valu e):

Adding 4 characters to the start of the 2nd line doesn't change the
meaning of the line.

There definitely were silent errors, like changing returns of
the sort

if x > 0:
return "positive"
return "nonpositiv e"

into

if x > 0:
return "positive"
return "nonpositiv e"

NB: This should be caught in any sort of unit test. The real test
is if it's hard to detect by a programmer; I'm not the one to
answer that test since I'm too used to Python. I suspect it is
generally easy to find, especially when the code is actually run,
but that it isn't always automatic.

I also figured given the quote counter example it wasn't
worthwhile categoring everything by hand.
[color=blue]
> Delete four adjacent spaces in a Python file. Will it still compile?
> Likely.[/color]

Here's test code. Note that I give each file 30 chances to succeed
after deleting 4 spaces, and it *never* did so. That surprised me as
I thought some of the hits would be in continuation blocks. There
may be a bug in my test code so I submit it here for review.

=============== ==
import string, random, os

def remove_random_4 _spaces(s):
x = s.split(" ")
if len(x) <= 1:
# needed for re.py which doesn't have 4 spaces
return "]]" # force a syntax error
i = random.randrang e(1, len(x))
x[i-1:i+1] = [x[i-1] + x[i]]
return " ".join(s)

def check_for_error s(filename):
s = open(filename). read()
for i in range(30):
t = remove_random_4 _spaces(s)
try:
exec t in {}
print "Success with", filename, "on try", i
return 0
except SyntaxError:
pass
return 1

def main():
dirname = os.path.dirname (string.__file_ _)
filenames = [name for name in os.listdir(dirn ame)
if name.endswith(" .py")]
count = 0
errcount = 0
problems = []
for filename in filenames:
print filename,
err = check_for_error s(os.path.join( dirname, filename))
if err:
errcount += 1
print "properly failed"
else:
print "still passed!"
problems.append (filename)
count += 1
print errcount, "correctly failed of", count
print "had problems with", problems

if __name__ == "__main__":
main()


=============== ==
anydbm.py properly failed
asynchat.py properly failed
asyncore.py properly failed
atexit.py properly failed
audiodev.py properly failed
base64.py properly failed
...
__future__.py properly failed
__phello__.foo. py properly failed
185 correctly failed of 185
had problems with []


Andrew
dalke@dalkescie ntific.com

[Erann Gat]

Re: Python syntax in Lisp and Scheme

In article <87ekxhl2k4.fsf @plato.moon.pao loamoroso.it>, Paolo Amoroso
<amoroso@mclink .it> wrote:

[A theory of with-maintained-condition]
[color=blue]
> Erann: is my understanding correct?[/color]

Yep. There are many plausible ways to implement
with-maintained-condition, and that's one of them.

E.

[ketil+news@ii.uib.no]

Re: Python syntax in Lisp and Scheme

Raffael Cavallaro <raffaelcavalla ro@junk.mail.me .not.mac.com> writes:
[color=blue]
> I think it is the mark of functional cleverness that people's code is
> filled with anonymous functions. These show you how the code is doing
> what it does, not what it is doing.[/color]

Uh, I often use a lambda because I think it improves readability.

I could write

(,) x . length . fst

but think

\(a,_) -> (x,lenght a)

is clearer, because it is *less* functionally clever. Of course, it
could be written

let pair_x_and_leng th_of_first (a,_) = (x,lenght a)
in pair_x_and_leng th_of_first

but I don't think it improves things, and in fact reduces lucidity and
maintainability . Naming is like comments, when the code is clear
enough, it should be minimized. IMHO.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

[Jacek Generowicz]

Re: Python syntax in Lisp and Scheme

"Daniel P. M. Silva" <dsilva@ccs.neu .edu> writes:
[color=blue]
> Please let me know if you hear of anyone implementing lisp/scheme in
> Python :)[/color]

Nah, I really don't want to hear about yet another personal Lisp
implementation. (Besides, somewhere, Alex Martelli implements a cons
cell as an example extension module, and that's half of Lisp done
already :-)

However, please _do_ tell me if you hear of anyone implementing Python
in Lisp[*].

Having Python as a front-end to Lisp[*] (as it is now a front-end to
C, C++ and Java) would be very interesting indeed.

[*] Common Lisp please.

[Terry Reedy]

Re: Python syntax in Lisp and Scheme


"Paul Foley" <see@below.inva lid> wrote in message
news:m2zng4w05m .fsf@mycroft.ac trix.gen.nz...[color=blue]
> True enough. Naming things is a pain though. Imagine if you[/color]
couldn't[color=blue]
> use numbers without naming them: e.g., if instead of 2 + 3 you had[/color]
to[color=blue]
> do something like
>
> two = 2
> three = 3
> two + three[/color]

For float constants in a language (such as Fortran) with multiple
float types (of different precisions), naming as part of a declaration
of precision is (or at least has been) a standard practice in some
circles. It makes it easy to change the precision used throughout a
program.
[color=blue]
> [Mind you, Python's lambda is next to useless anyway][/color]

It is quite useful for its designed purpose, which is to abbreviate
and place inline short one-use function definitions of the following
pattern: def _(*params): return <expression using params>.

However, making the keyword 'lambda' instead of something like 'func'
was a mistake for at least two reasons:
1) it confuses those with no knowledge of lambda calculus and for whom
it is an strange, arbitrary term, possibly conjuring images of little
sheep, rather than being familar and mnemonic;
2) it raises unrealistic expectations in who know of 'lambda' as an
anonymous version of 'defun' (or whatever), leading them to make
statements such as the above.

Terry J. Reedy

[Paul Rubin]

Re: Python syntax in Lisp and Scheme

Jacek Generowicz <jacek.generowi cz@cern.ch> writes:[color=blue]
> However, please _do_ tell me if you hear of anyone implementing Python
> in Lisp[*].
>
> Having Python as a front-end to Lisp[*] (as it is now a front-end to
> C, C++ and Java) would be very interesting indeed.[/color]

That would not be simple to do, because of weird Python semantics.
But doing a Python dialect (a little bit different from CPython) would
be worthwhile.

[Raffael Cavallaro]

Re: Python syntax in Lisp and Scheme

In article <8yno1dvi.fsf@c omcast.net>, prunesquallor@c omcast.net wrote:
[color=blue]
> (flet ((add-offset (x) (+ x offset)))
> (map 'list #'add-offset some-list))[/color]

But flet is just lambda in drag. I mean real, named functions, with
defun. Then the code becomes:

(add-offset the-list)

instead of either of theversions you gave. The implementation details of
add-offset are elswere, to be consulted only when needed. They don't
interrupt the flow of the code, or the reader's understanding of what it
does. If you need that optimization, you can always throw in (declaim
(inline 'add-offset)) before add-offset's definition(s).

I guess I'm arguing that the low level implementation details should not
be inlined by the programmer, but by the compiler. To my eye, anonymous
functions look like programmer inlining.

[David Eppstein]

Re: Python syntax in Lisp and Scheme

In article <tyf1xtf50a5.fs f@pcepsft001.ce rn.ch>,
Jacek Generowicz <jacek.generowi cz@cern.ch> wrote:
[color=blue]
> However, please _do_ tell me if you hear of anyone implementing Python
> in Lisp[*].
>
> Having Python as a front-end to Lisp[*] (as it is now a front-end to
> C, C++ and Java) would be very interesting indeed.[/color]

It is now also a front-end to Objective C, via the PyObjC project.

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Terry Reedy]

Re: Python syntax in Lisp and Scheme


<prunesquallor@ comcast.net> wrote in message

Thank you for the clarification. The message for me is this: a
Python-aware editor should have an option to keep a pasted-in snippet
selected so that the indentation can be immediately adjusted by the
normal selected-block indent/dedent methods without having to
reselect.

TJR

[Terry Reedy]

Re: Python syntax in Lisp and Scheme


<prunesquallor@ comcast.net> wrote in message
news:8yno1dvi.f sf@comcast.net. ..[color=blue]
> I disagree. This:
>
> (map 'list (lambda (x) (+ x offset)) some-list)
>
> is clearer than this:
>
> (flet ((add-offset (x) (+ x offset)))
> (map 'list #'add-offset some-list))[/color]

I agree for this example (and for the Python equivalent). But if the
function definition is several lines, then I prefer to have it defined
first so that the map remains a mind-bite-sized chunk.

TJR

[Thant Tessman]

Re: Python syntax in Lisp and Scheme

Raffael Cavallaro wrote:
[color=blue]
> [...] Actually, I think that any anonymous function syntax is undesirable. I
> think code is inerently more readable when functions are named,
> preferably in a descriptive fashion. [...][/color]

Before the invention of higher-level languages like Fortran, the
programmer was burdened with the task of naming every intermediate value
in the calculation of an expression. A programmer accustomed to the
functional style finds the need in non-FP languages to name every
function analogously awkward.

-thant

--
America goes not abroad in search of monsters to destroy. She is
the well-wisher of the freedom and independence of all. She is
the champion and vindicator only of her own. -- John Quincy Adams

[Joe Marshall]

Re: Python syntax in Lisp and Scheme

Raffael Cavallaro <raffaelcavalla ro@junk.mail.me .not.mac.com> writes:
[color=blue]
> In article <8yno1dvi.fsf@c omcast.net>, prunesquallor@c omcast.net wrote:
>[color=green]
>> (flet ((add-offset (x) (+ x offset)))
>> (map 'list #'add-offset some-list))[/color]
>
> But flet is just lambda in drag. I mean real, named functions, with
> defun. Then the code becomes:
>
> (add-offset the-list)[/color]

I'm assuming that offset is lexically bound somewhere outside
the let expression so that I have to capture it with an in-place
FLET or LAMBDA. If we had an external add-offset then I'd have
to do something like

(add-offset offset some-list)

The problem with this is that you've essentially outlawed MAP.

(map 'list (make-adder offset) some-list)

The problem with this is that MAKE-ADDER is no less a lambda in drag,
and it isn't even local.

[Dave Benjamin]

Re: Python syntax in Lisp and Scheme

In article <bmh6p4$7b2$1@t erabinaries.xmi ssion.com>, Thant Tessman wrote:[color=blue]
>
> Before the invention of higher-level languages like Fortran, the
> programmer was burdened with the task of naming every intermediate value
> in the calculation of an expression. A programmer accustomed to the
> functional style finds the need in non-FP languages to name every
> function analogously awkward.[/color]

Well put, Thant. Thank you.

--
..:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g l i f e o u t o f t h e c o n t a i n e r :