Python syntax in Lisp and Scheme

[Avi Blackmore]

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

"Greg Ewing (using news.cis.dfn.de )" <g2h5dqi002@sne akemail.com> wrote in message news:<bmd2js$l3 vkg$1@ID-169208.news.uni-berlin.de>...

[snip][color=blue]
>
> From that point of view, "car" and "cdr" are as good
> as anything![/color]

Better in one sense, I think. With "first" and "rest", you can't
have fun making bumper stickers that say "My other car is a cdr."

Avi Blackmore

[Bengt Richter]

Re: Python syntax in Lisp and Scheme

On Thu, 16 Oct 2003 23:10:52 -0400, mertz@gnosis.cx (David Mertz) wrote:
[color=blue]
>|>And you DO NOT NEED lambdas for HOFs!
>
>bokr@oz.net (Bengt Richter) wrote previously:
>|there could be ways that you need BOTH named and un-named functions.
>
>Nope, you do not NEED both. It can be convenient or expressive to have
>both, but it is certainly not necessary for HOFs or any other
>computationa l purpose. And I have yet to see an example where a
>hypothetical loss of unnamed functions would *significantly* worsen
>expressiveness .
>
>|a function NEEDS a name in order to call itself recursively[/color]
You snipped the line following the preceding:
(unless you create some specialized syntax for a recursive call)
[color=blue]
>
>Nope. That's the point of the Y combinator; you don't need a name to do
>this (just first class anonymous functions). See, for example:
>
> http://en2.wikipedia.org/wiki/Y_combinator[/color]
I'd call that a specialized syntax, to serve my purposes ;-)
[color=blue]
>
>|OTOH, if you evaluate a def in a namespace where you don't know what
>|all the names are, you have a collision risk when you choose a name.
>|An un-named function eliminates that risk.
>
>Sure, that can occassionally be useful in eliminating the small risk.
>But so can 'grep'. There are always more names out there to use. This
>particular convenience is VERY small.[/color]
That's what I meant by the first line in
"""
Practically, it is probably rare that you can't use a named function,
but really def is a convenience construct that does name binding after
doing (what would be) a full-fledged lambda thing IMO.
"""[color=blue]
>
>|Why should the following kind of thing be arbitrarily restricted?
>| >>> funlist = [
>| ... (lambda value:
>| ... lambda:'My value is %s'%value
>| ... # imagine freedom to have full suites here
>| ... )(y) for y in range(5)
>| ... ]
>| >>> for fun in funlist: print fun()
>
>Obviously, you cannot spell 'funlist' quite that way in Python. But the[/color]
The above spelling works fine, being verbatim cut/paste). Just not if you want
to replace the comment as it invites you to imagine. I guess the hypothetical
version is what you were referring to by 'that way.'
[color=blue]
>available spellings are not bad looking IMO. E.g., with no lambda:[/color]
I pre-agreed, following my example with:
"""
(Not that a bound method (aka callable object if bound method is __call__) might
not be as good or better in many cases, ...
"""[color=blue]
>[color=green][color=darkred]
> >>> def ValFactory(x):[/color][/color]
> ... def say_val(x=x): return 'My value is %s' % x
> ... return say_val
> ...[color=green][color=darkred]
> >>> funlist = map(ValFactory, range(5))[/color][/color]
>
>I'm not sure the point here. My spelling happens to be Python's (or at
>least one option in Python)... and it works fine without any lambdas.[/color]

The relevant phrase from the post you are replying to was
"... where the def names would at best be ignored side effects." (Although
you are forced to use the temp bindings to return the function).
[color=blue]
>If you want, you can even 'del' the name 'ValFactory' after the list is
>created.[/color]
Sure. Interesting you chose to use the default-value hack rather than
a closure ;-). What I had in mind when I pre-agreed was something like
[color=blue][color=green][color=darkred]
>>> class SayVal(object):[/color][/color][/color]
... def __init__(self, v): self.v=v
... def __call__(self): return 'My value is %s' % self.v
...[color=blue][color=green][color=darkred]
>>> funlist = map(SayVal, range(5))
>>> for f in funlist: print f()[/color][/color][/color]
...
My value is 0
My value is 1
My value is 2
My value is 3
My value is 4

Regards,
Bengt Richter

[james anderson]

Re: Python syntax in Lisp and Scheme



David Mertz wrote:[color=blue]
>
> ...
>
> |a function NEEDS a name in order to call itself recursively
>
> Nope. That's the point of the Y combinator; you don't need a name to do
> this (just first class anonymous functions). See, for example:
>
> http://en2.wikipedia.org/wiki/Y_combinator
>[/color]

please bear with me on something which i have evidently misunderstood.
what are the symbols 'h' and 'x' in the referenced exposition on the "y
combinator" if they are not names?
is the essential distinction, that one does not "need" free "names"?

?

[Raffael Cavallaro]

Re: Express What, not How.

In article <3f8e1312@news. sentex.net>,
hs@heaven.nirvananet (Hartmann Schaffer) wrote:
[color=blue]
> map is an abstraction that
> specifies that you want to apply a certain operation to each element
> of a collection, with adding the offset being the desired operation.[/color]

Sorry to reply so late - I didn't see this post.

In the context in which the offsets are added, it isn't necessary to
know that the offsets are added using map, as opposed, for example, to
an interative construct, such as loop. Since we don't need to know _how_
the adding of offsets is done at every location in the source where we
might want to add an offset to the elements of a list or vector, we
should _name_ this bit of functionality. This is an even bigger win
should we ever decide to switch from map to loop, or do, or dolist, etc.
Then we write a single change, not one for every time we use this bit of
functionality.

[Pascal Costanza]

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

Hartmann Schaffer wrote:
[color=blue]
> In article <bmgh32$1a32$1@ f1node01.rhrz.u ni-bonn.de>,
> Pascal Costanza <costanza@web.d e> writes:
>[color=green]
>>...
>>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[/color]

Yes, but noone (noone at all) refers to that meaning anymore. It's a
historical accident that doesn't really matter anymore when developing code.


Pascal

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Marcin 'Qrczak' Kowalczyk wrote:
[color=blue]
> Because these hard-coded syntaxes are prettier than the extensible Lisp
> syntax full of parentheses.[/color]

Obviously, you haven't tried to actually program in Lisp. Getting used
to the syntax is a matter of one or two weeks at most of actual coding,
provided you use a decent editor that supports parenthesis highlighting
and automatic indentation.

Despising Lisp because of its syntax is like thinking that Japanese is a
too complicated language because it doesn't use latin characters.


Mind you, I had more or less exactly the same objections to Lisp's
syntax about one and a half year ago. Now, I don't see any language out
there that nearly provides the same level of usability than Lisp,
exactly because of its regular syntax "full of parentheses". It's far
prettier and easier to read than languages whose syntaxes are based on
some unreflected, purely aesthetical choices.


Pascal

[Raffael Cavallaro]

Re: Express What, not How.

In article <87ad80iets.wl@ strelka.synthco de.com>,
Alex Shinn <foof@synthcode .com> wrote:[color=blue]
> My point is the
> result of applying the HOF gives us "run quickly" which is itself a
> function, and an anonymous one at that because "run quickly" is not a
> name but a visible application of an HOF.[/color]


I have no problem with a HOF, as long as the HOF corresponds to
something in the language of the problem domain. But it doesn't here. I
think it is telling that your example is taken from the problem domain
of computer science (memoization of functions), not that of the domain.

[color=blue]
> It's exactly equivalent to
>
> (memoize run)[/color]

If we were writing a program that simulated people running and swimming,
it's very doubtful that "quickly" would mean "memoize." "Quickly" would
mean, "with-increased-framerate," or something similar. (Note that
with-increased-framerate would almost certainly be a macro).

In domains outside of functional programming and mathematics, the
concepts of the problem domain don't usually map to applicable HOFs.
People fall in love with HOFs because they are great tools for lower
level implementation. But I don't think they usually map well to the
concepts of problem domains other than mathematics and computer science.
Named functions and macros let us capture the power of HOFs inside a
vocabulary _and_ syntax that matches the problem domain.

[Ray Blaak]

Re: Python syntax in Lisp and Scheme

mertz@gnosis.cx (David Mertz) writes:[color=blue]
> |a function NEEDS a name in order to call itself recursively
>
> Nope. That's the point of the Y combinator; you don't need a name to do
> this (just first class anonymous functions).[/color]

Actually you do need a name. The Y combinator is just a way to give a name to
the anonymous function, where the name is a parameter name. It is only with
that name that the recursive invocation is done.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYblaaK@STRIPC APStelus.net The Rhythm has my soul.

[Hans Nowak]

Re: Python syntax in Lisp and Scheme

Jan Rychter wrote:
[color=blue]
> I've recently tried to teach someone programming. I thought "Python has
> an easy syntax, let's try that". Well, guess what -- she had a really
> hard time. Inconsistency was a real problem, as was the confusion
> between "statements " and "expression s". When you start programming in
> Python, you get really confused -- does this call have side effects or
> not? You can't tell by looking at the call.[/color]

Strange. A beginner shouldn't have a problem with the distinction between
statements and expressions, and shouldn't know about side effects at all, since
this is a notion introduced by functional languages. Does this beginner, by
any chance, come from a functional programming language, or maybe a strong
mathemathical background?
[color=blue]
> Also, the syntax was confusing. Yes, indenting the statements is
> easy. But the dot notation is all but obvious, especially with its
> inconsistent application in Python.[/color]

How is it inconsistent? It's used to access an object's attributes.
[color=blue]
> And where did those square brackets
> suddenly come from and when do I use them?[/color]

They're syntactic sugar indicating a "data lookup" of some sorts, hence their
application with dicts and lists.
[color=blue]
> Mind you, this is from a beginner's point of view. Most of you look at
> the language syntax from the point of view of a person knowing at least
> one (or more) programming languages and having the basic programming
> concepts drilled in. It's very different for someone who does not have
> that background.[/color]

It's possible I guess, different beginners have different ideas, expectations
and experiences, but usually the opposite is true... beginners find Python easy
to use.
[color=blue]
> An experiment has shown that Scheme was *much* easier to grasp. In
> Scheme, you can clearly see where side-effects occur and there are less
> syntax rules to follow.[/color]

Again, this raises my suspicions that the beginners that were tested have a
mathemathical background. Heck, beginners used Basic for ages... I haven't
heard anyone complain about statements vs expressions, or side effects. They
usually don't even know the distinction.

Cheers,

--
Hans (hans@zephyrfal con.org)

http://zephyrfalcon.org/

[David Mertz]

Re: Python syntax in Lisp and Scheme

|mertz@gnosis.c x (David Mertz) writes:
|> |a function NEEDS a name in order to call itself recursively
|> Nope. That's the point of the Y combinator; you don't need a name to do
|> this (just first class anonymous functions).

Ray Blaak <rAYblaaK@STRIP CAPStelus.net> wrote previously:
|Actually you do need a name. The Y combinator is just a way to give a name to
|the anonymous function, where the name is a parameter name. It is only with
|that name that the recursive invocation is done.

Well, OK. This is true. But the context was basically whether you
could write whole programs as big lambda abstractions--e.g. Lisp minus
'defun' and 'set', or Python minus 'def'.

"Normal" recursive programs let the programmer know the name of the
function she is writing, and use that name for the recursion call. You
could use the Y combinator even if pixies would come it at random and
change the bound name 'h' to something else, throughout your code; the
name itself is never -used- beyond the lambda.

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> ]--------------------------

[David Mertz]

Re: Python syntax in Lisp and Scheme

bokr@oz.net (Bengt Richter) wrote previously:
|>Nope. That's the point of the Y combinator; you don't need a name to do
|>this (just first class anonymous functions). See, for example:
|> http://en2.wikipedia.org/wiki/Y_combinator
|I'd call that a specialized syntax, to serve my purposes ;-)

Well... it's specialized. But it's not a syntax, just a somewhat odd
HOF. But I would definitely agree that I don't want all my recursion to
be based on anonymous functions.

|>This particular convenience is VERY small.
|That's what I meant by the first line in

Yeah, but I put the 'very' in caps :-).

|the hypothetical version is what you were referring to by 'that way.'

Yeah, sorry about my pronoun. I meant "can't spell the full suite..."

|> >>> def ValFactory(x):
|> ... def say_val(x=x): return 'My value is %s' % x
|> ... return say_val
|Sure. Interesting you chose to use the default-value hack rather than
|a closure ;-). What I had in mind when I pre-agreed was something like
| >>> class SayVal(object):
| ... def __init__(self, v): self.v=v
| ... def __call__(self): return 'My value is %s' % self.v

Well... the "default value hack" *IS* a closure.

I know I'm in the minority here, but it feels like more of a hack to me
to make class instances whose (main) purpose is to "act like functions"
(i.e. have custom '.__call__()' methods). In my mind, when I want a
bunch of related callables, the natural approach is writing a function
factory, not a class.

But either way, Bengt's is another perfectly good spelling for a
collection of callables that allow full suites. Not being Dutch, I
can't say which one is the "one obvious way."

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 <mailman.181.10 66417144.2192.p ython-list@python.org >, David Mertz wrote:[color=blue]
>
> I know I'm in the minority here, but it feels like more of a hack to me
> to make class instances whose (main) purpose is to "act like functions"
> (i.e. have custom '.__call__()' methods). In my mind, when I want a
> bunch of related callables, the natural approach is writing a function
> factory, not a class.[/color]

In most cases, I would completely agree with you. Though they are often
interchangeable (closures and callable objects), there is a subtle semantic
difference to me. Is it a stateful function or a callable object? What does
it feel like? I usually go with my intuition.

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

[Vis Mike]

Re: Express What, not How.


"Luke Gorrie" <luke@bluetail. com> wrote in message
news:lhad81igl6 .fsf@dodo.bluet ail.com...[color=blue]
> ketil+news@ii.u ib.no writes:
>[color=green]
> > Anonymous functions *can* be more clear than any name. Either because
> > they are short and simple, because it is hard to come up with a good
> > name, and/or becuase they are ambigous.
> >
> > Say I want to attach an index to elements of a list. I could write
> >
> > integers = [1..]
> > attach_index ls = zip integers ls
> >
> > or just
> >
> > attach_index ls = zip [1..] ls[/color]
>
> If we're arguing to eliminate names that don't say very much, then
>
> attach_index = zip [1..][/color]

I think dynamic scoping within blocks really trims down on duplication and
make the code easier to read. For example:

employees sort: [ | a b | a date < b date ]

A lot of typing for a simple concept:

employees sort: [ < data ]

I'm not against too much typing to be clear, but rather too much typping
that makes the concept unclear.

-- Mike
[color=blue][color=green]
> > Whether you want to give an explicit name to the list of integers is
> > not given. If the indexed list is local, it is better to use the
> > definition directly; I don't want to look up the definition of
> > integers (perhaps in a different module) to check whether it is [1..]
> > or [0..].[/color]
>
> And for the exact same reason you might like to just write "zip [1..]"
> instead of using a separate "attach_ind ex" function.
>
> Cheers,
> Luke
>[/color]

[Pascal Bourguignon]

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

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> Hartmann Schaffer wrote:
>[color=green]
> > In article <bmgh32$1a32$1@ f1node01.rhrz.u ni-bonn.de>,
> > Pascal Costanza <costanza@web.d e> writes:
> >[color=darkred]
> >>...
> >> 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[/color]
>
> Yes, but noone (noone at all) refers to that meaning anymore. It's a
> historical accident that doesn't really matter anymore when developing
> code.[/color]

For that matter, even the very first LISP _programmer_ did not refer
to that meaning either.

Only the _implementer_ of the first LISP did.

--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

Do not adjust your mind, there is a fault in reality.
Lying for having sex or lying for making war? Trust US presidents :-(

[Rainer Deyke]

Re: Python syntax in Lisp and Scheme

Ray Blaak wrote:[color=blue]
> Actually you do need a name. The Y combinator is just a way to give a
> name to the anonymous function, where the name is a parameter name.
> It is only with that name that the recursive invocation is done.[/color]

This is technically not true. See
http://www.eleves.ens.fr:8080/home/m...a/#lambda_elim.


--
Rainer Deyke - rainerd@eldwood .com - http://eldwood.com