Python syntax in Lisp and Scheme

[Hartmann Schaffer]

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

In article <bmgh32$1a32$1@ f1node01.rhrz.u ni-bonn.de>,
Pascal Costanza <costanza@web.d e> writes:[color=blue]
> ...
> I think that's the essential point here. The advantage of the names car
> and cdr is that they _don't_ mean anything specific.[/color]

gdee, you should read early lisp history ;-). car and cdr ha[d|ve] a
very specific meaning

hs

--

ceterum censeo SCO esse delendam

[Hartmann Schaffer]

Re: Python syntax in Lisp and Scheme

In article <6mWdnVM6bOIOiR GiU-KYhA@comcast.co m>,
"Terry Reedy" <tjreedy@udel.e du> writes:[color=blue]
> ...[color=green]
>> 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]

this is a good practice when the literals are parameters that you want
to change occasionally. other reasons why you want to do that is that
typing certain constants (e.g. pi or e) is error prone, so writing
them down once and binding them to a (descriptive) name is preferrably
to having to type them repeatedly. but unless they play a parameter
role, binding short literals to name doesn't serve any purpose
[color=blue][color=green]
>> [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>.[/color]

the last version of python i used was 1.5.x, and then the absence of
closures made the anonymous functions pretty useless
[color=blue]
> ...[/color]

hs

--

ceterum censeo SCO esse delendam

[Hartmann Schaffer]

Re: Python syntax in Lisp and Scheme

In article <raffaelcavalla ro-583E78.11332714 102003@netnews. attbi.com>,
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)
>
> instead of either of theversions you gave.[/color]

the version he gave has the advantage that it doesn't clutter up the
namespace of the environment. with

(map (lambda (x) (+ x offset)) the-list)

you have everything that is relevant in the immediate neighborhood of
the statement. with a separate defun you have to search the program
to see what the function does. i agree that for lengthy functions
defining it separately and just writing the name is preferrable.
[color=blue]
> ...
> 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.[/color]

i would call this a misconception

hs

--

ceterum censeo SCO esse delendam

[Hartmann Schaffer]

Re: Python syntax in Lisp and Scheme

In article <q-KdncVZlO2AgxGiU-KYgw@comcast.co m>,
"Terry Reedy" <tjreedy@udel.e du> writes:[color=blue]
>
> <prunesquallor@ comcast.net> wrote in message
> news:8yno1dvi.f sf@comcast.net. ..[color=green]
>> 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.[/color]

i agree with your evaluation of what is preferrablem but i think you
would be surprised how clear the amove construct can look when
properly indented (something a decent editor would do automatically)

hs

--

ceterum censeo SCO esse delendam

[Kaz Kylheku]

Re: Python syntax in Lisp and Scheme

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> wrote in message news:<pan.2003. 10.13.21.26.56. 715704@knm.org. pl>...[color=blue]
> On Mon, 13 Oct 2003 13:51:22 -0700, Kaz Kylheku wrote:
>[color=green]
> > Secondly, it would be unoptimizeable. The result of evaluating a
> > lambda expression is an opaque function object. It can only be called.[/color]
>
> This is not true. When the compiler sees the application of a lambda,
> it can inline it and perform further optimizations, fusing together
> its arguments, its body and its context.[/color]

Kindly keep in mind the overall context of the discussion, which is
HOF's versus macros. The closures being discussed are ones passed down
into functions. Those closures typically cannot be inlined, except
under very special circumstances taken advantage of by a compiler with
very smart global optimizations.

[Donn Cave]

Re: Python syntax in Lisp and Scheme

In article <m2zng4w05m.fsf @mycroft.actrix .gen.nz>,
Paul Foley <see@below.inva lid> wrote:[color=blue]
> On Tue, 14 Oct 2003 01:26:54 -0400, David Mertz wrote:[/color]
....[color=blue][color=green]
>> 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][/color]

Sure, Python is a procedural programming language with things
like "if" statements that don't play very well in the context
of a lambda body, and with a notion of identifiers, variables
and scope that doesn't favor some of the conveniences that
lambda writers enjoy in functional programming languages. So
lambda is doomed to suffer from some limitations, and this seems
to bug some people no end.

It isn't clear that there's a real problem here, though, as
opposed to an occasion for contributing to the hot air supply
on USENET. (Heavens, what possessed me to read any of this
thread!?) Even if you suppose that Python programmers have
the same need for lambdas as one would in an FPL, what little
value they have is clearly in just the kind of applications
that actually work in Python anyway. The last time this came
up in another newsgroup, I rewrote a sort of well known
snippet of Haskell (a state monad) with named functions in
place of the lamdbdas the way you always see it, and proposed
that it was easier to read that way, and if anyone came forward
to contradict me I don't recall it. I think there is some
perverse thriftiness in most of us that makes us want to economise
on a carriage return here a name there, until our code becomes
so distilled that it's too perfect - too hard to understand.
Python is not about this kind of perfection, in my opinion.

Donn Cave, donn@u.washingt on.edu

[Matthias Blume]

Re: Python syntax in Lisp and Scheme

kaz@ashi.footpr ints.net (Kaz Kylheku) writes:
[color=blue]
> Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> wrote in message news:<pan.2003. 10.13.21.26.56. 715704@knm.org. pl>...[color=green]
> > On Mon, 13 Oct 2003 13:51:22 -0700, Kaz Kylheku wrote:
> >[color=darkred]
> > > Secondly, it would be unoptimizeable. The result of evaluating a
> > > lambda expression is an opaque function object. It can only be called.[/color]
> >
> > This is not true. When the compiler sees the application of a lambda,
> > it can inline it and perform further optimizations, fusing together
> > its arguments, its body and its context.[/color]
>
> Kindly keep in mind the overall context of the discussion, which is
> HOF's versus macros. The closures being discussed are ones passed down
> into functions. Those closures typically cannot be inlined, except
> under very special circumstances taken advantage of by a compiler with
> very smart global optimizations.[/color]

If a macro works in a particular situation, then any equivalent HOF
can be inlined there as well. Granted, not all compilers will
actually do so, but the possibility trivially exists. This does not
depend on "very smart" global optimizations.

Matthias

[Daniel P. M. Silva]

Re: Python syntax in Lisp and Scheme

On Tue, 14 Oct 2003 17:03:46 +0200, Jacek Generowicz 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.
>
>[*] Common Lisp please.[/color]

You could always port Spy to CL (mentioned elsewhere in the thread).

- DS

[David Mertz]

Re: Python syntax in Lisp and Scheme

Paul Foley <see@below.inva lid> wrote previously:
|True enough. Naming things is a pain though. Imagine if you couldn't
|use numbers without naming them:

This is plain idiotic. Someone else posted it equally disingenuously
too, FWIW.

Numbers aren't functions. Just because you can take a noun from a
sentence, and insert a different noun that changes the truth value is
REALLY not interesting. Let's try it:

Imagine you couldn't use MACROS without naming them
Imagine you couldn't use MODULES without naming them
Imagine you couldn't use KEYWORDS without naming them
...

If you want to suggest some ACTUAL advantage to HOFs, fine. Do it. But
please no annoying non-analogies.

In any case, I started my little splinter only in response to someone
who claimed that you needed lambdas to use HOFs. An obviously wrong,
and annoyingly stupid, claim. Pointing out that Haskell or Python could
easily drop lambda, with no detriment, simply makes that point.

Yours, David...

--
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <mertz@gnosis.c x> ]--------------------------

[Dave Benjamin]

Re: Python syntax in Lisp and Scheme

In article <donn-9E699D.10085714 102003@nntp1.u. washington.edu> , Donn Cave wrote:[color=blue]
>
> ...to contradict me I don't recall it. I think there is some
> perverse thriftiness in most of us that makes us want to economise
> on a carriage return here a name there, until our code becomes
> so distilled that it's too perfect - too hard to understand.
> Python is not about this kind of perfection, in my opinion.[/color]

True, but there are other reasons for anonymity besides the conservation of
character count (heh). Sometimes, you just don't know if something needs to
be reusable. Maybe YAGNI. For me, I typically go through an exploratory
phase when writing a new module where I don't name a lot of things, don't
create a lot of objects, and just try to solve a problem. I find that the
ability to toss around "thunks" helps me find a solution through
experimentation . Once the code is solid, I lift anonymous functions and
extract methods and classes where access patterns dictate the ability to
reuse and eliminate redundancy. At this point, I actually see the solution,
so I don't have to anticipate what sort of structure I'm going to need.

This is just one manner of solving problems, of course. However, it happens
to work particularly well (for me) in new domains which I lack the
experience necessary to work out a good structure in advance. With every
named object in a program comes the implicit assumption that the object will
later need to be called for by name. This goes for functions, classes, and
temporary variables.

I'm not trying to jump into the fire here, but I just wanted to illustrate
how anonynimity might be about imperfection, too. After all, you can always
repent^H^H^H^Hf actor later. =)

Peace,
Dave

--
..:[ 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 :

[Terry Reedy]

Re: Python syntax in Lisp and Scheme


"Hartmann Schaffer" <hs@heaven.nirv ananet> wrote in message
news:3f8c24c6@n ews.sentex.net. ..[color=blue]
> In article <6mWdnVM6bOIOiR GiU-KYhA@comcast.co m>,
> "Terry Reedy" <tjreedy@udel.e du> writes:[color=green]
> > For float constants in a language (such as Fortran) with multiple
> > float types (of different precisions), naming as part of a[/color][/color]
declaration[color=blue][color=green]
> > of precision is (or at least has been) a standard practice in some
> > circles. It makes it easy to change the precision used throughout[/color][/color]
a[color=blue][color=green]
> > program.[/color]
>
> this is a good practice when the literals are parameters that you[/color]
want[color=blue]
> to change occasionally. other reasons why you want to do that is[/color]
that[color=blue]
> typing certain constants (e.g. pi or e) is error prone, so writing
> them down once and binding them to a (descriptive) name is[/color]
preferrably[color=blue]
> to having to type them repeatedly. but unless they play a parameter
> role, binding short literals to name doesn't serve any purpose[/color]

My last sentence above gives a purpose, which is *the* purpose which
lead the editors of Applied Statistics to 'strongly advise' (up to
1985 at least, don't know about today) algorithm authors to "denote
all REAL constants symbolically" (A. S. Algorithms, p. 30). I'm just
reporting, not advocating. This in not an issue for standard Python,
which only allows access to C doubles.
[color=blue][color=green][color=darkred]
> >> [Mind you, Python's lambda is next to useless anyway][/color]
> >
> > It is quite useful for its designed purpose, which is to[/color][/color]
abbreviate[color=blue][color=green]
> > and place inline short one-use function definitions of the[/color][/color]
following[color=blue][color=green]
> > pattern: def _(*params): return <expression using params>.[/color]
>
> the last version of python i used was 1.5.x, and then the absence of
> closures made the anonymous functions pretty useless[/color]

The default-parameter hack which substituted for closures made lambdas
then more awkward, but I believe they were mostly just as useful as
today as callbacks and as HOF args. In any case, closures were
introduced over two years ago in 2.1, and your original statement says
'is', not 'used to be some years ago'.

Terry J. Reedy

[Shmuel (Seymour J.) Metz]

Re: Science is a human activity (was: Python syntax in Lisp and Scheme)

In <odbmovck6v38on q2ufum0obkf9n2n 9gsvc@4ax.com>, on 10/13/2003
at 06:03 PM, David C. Ullrich <ullrich@math.o kstate.edu> said:
[color=blue]
>Well it certainly _can_ be formalized. (Have you any experience with
>_axiomatic_ Euclidean geometry?[/color]

That's not the same thing as formalized. Such authors as Hilbert left
out steps that were formally necessary but would have obscured the
reader's understanding.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action. I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me. Do
not reply to spamtrap@librar y.lspace.org

[Alexander Schmolck]

Re: Python syntax in Lisp and Scheme

"Terry Reedy" <tjreedy@udel.e du> writes:
[color=blue]
> <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.[/color]

emacs. Just press C-c> or C-c< right after pasting.

'as

[Raffael Cavallaro]

Express What, not How.

In article <bmh6p4$7b2$1@t erabinaries.xmi ssion.com>,
Thant Tessman <thant@acm.or g> wrote:
[color=blue]
> A programmer accustomed to the
> functional style finds the need in non-FP languages to name every
> function analogously awkward.[/color]

No one is talking about need, but about clarity of exposition.

It is perfectly possible to program functionally in lisp, as I'm sure
you know. It just makes code less readable to use _anonymous_ functions.
Code is no less functional when the functions are named.

A theme of this whole thread is the difference between writing _what_
something does, and _how_ it does it. The higher up the ladder of
abstraction we go, the more we want to express _what_ is being done. We
leave the _how_ defined elsewhere, to be consulted only as needed.

Anonymous functions force the _how_ to be interleaved with the _what_,
breaking up the clarity of the _what_. Named functions (and macros)
allow the high level abstractions to be expressed in terms of _what_ is
happening, without unnecessary reference to _how_.

Anonymous functions force the reader to deal with _how_ precisely
because there is no descriptive name that expresses _what_ the funtion
does. This is an inappropriate conflation of two distinct purposes, that
can and should be separated in source code.

[David C. Ullrich]

Re: Science is a human activity (was: Python syntax in Lisp and Scheme)

On Tue, 14 Oct 2003 14:38:42 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@libra ry.lspace.org.i nvalid> wrote:
[color=blue]
>In <odbmovck6v38on q2ufum0obkf9n2n 9gsvc@4ax.com>, on 10/13/2003
> at 06:03 PM, David C. Ullrich <ullrich@math.o kstate.edu> said:
>[color=green]
>>Well it certainly _can_ be formalized. (Have you any experience with
>>_axiomatic_ Euclidean geometry?[/color]
>
>That's not the same thing as formalized.[/color]

Of course it's not. But it seems to me that his skepticism regarding
whether that proof _can_ be formalized must in fact be skeptism
regarding whether it's possible to state all the necessary axioms
and deduce the theorem without any appeal to the way things
look.
[color=blue]
>Such authors as Hilbert left
>out steps that were formally necessary but would have obscured the
>reader's understanding.[/color]

*************** *********

David C. Ullrich