Python syntax in Lisp and Scheme

[A. Lloyd Flanagan]

Re: Python syntax in Lisp and Scheme

Pascal Costanza <costanza@web.d e> wrote in message news:<bm66jn$pi 8$1@f1node01.rh rz.uni-bonn.de>...[color=blue]
> David Eppstein wrote:[color=green]
> > In article <bm4uf6$6oj$1@n ewsreader2.netc ologne.de>,
> > Pascal Costanza <costanza@web.d e> wrote:
> >
> >[color=darkred]
> >>It's probably just because the Common Lisp community is still relatively
> >>small at the moment. But this situation has already started to improve a
> >>lot.[/color]
> >
> >
> > It's only been out, what, twenty years? And another twenty before that
> > for other lisps... How much time do you think you need?[/color]
>
> AFAIK, Lisp was very popular in the 70's and 80's, but not so in the
> 90's. At the moment, Common Lisp is attracting a new generation of
> programmers.
>[/color]

I was a Lisp fan back when Common Lisp came out. We went from a
stunningly simple language that could be described in a small booklet
to one that couldn't be adequately described in a 300-page tome. It
was about that time that Lisp dropped off the radar.

Now I have a language called Python, which like the original Lisp can
be described simply but has extraordinary power. And _it_ is what is
attracting a new generation of programmers.

[Ken Shan]

Re: Express What, not How.

Raffael Cavallaro <raffaelcavalla ro@junk.mail.me .not.mac.com> wrote in article <raffaelcavalla ro-20C5F3.01461917 102003@netnews. attbi.com> in comp.lang.funct ional:[color=blue]
> I think you miss the point - "quickly" is itself a _name_ for an
> abstract modifier. If this is the analog of a higher order function, it
> is a _named_ higher order function, not an anonymous one.[/color]

In what sense are "lambda" and "apply" not names?

--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
"Who needs drugs when we have sex and chocolate?" -- Cory Kerens

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

A. Lloyd Flanagan wrote:
[color=blue]
> I was a Lisp fan back when Common Lisp came out. We went from a
> stunningly simple language that could be described in a small booklet
> to one that couldn't be adequately described in a 300-page tome. It
> was about that time that Lisp dropped off the radar.
>
> Now I have a language called Python, which like the original Lisp can
> be described simply but has extraordinary power. And _it_ is what is
> attracting a new generation of programmers.[/color]

Common Lisp still has a small core, and most of the stuff of the indeed
large spec would rather be considered standard libraries in more
conventional languages.

Yes, it would probably have been better if Common Lisp designers would
have made this distinction clearer, for example by defining language
layers. That's maybe the only real mistake they have made. [1]


Pascal

[1] Somewhere in this thread someone accused "us" Lispers that we don't
admit that Lisp has "bad" features. The reason why wo don't admit
anything here is not because it doesn't have bad features, but because
the flexibility of Lisp always allows us to code around these
misdesigns. And we don't have to wait for some language designer to
release version x.y of the language to fix a feature of the language.

The fact that Common Lisp is large is indeed the only mistake that we
can't "code around".

[Raffael Cavallaro]

Re: Express What, not How.

In article <t76661-316.ln1@proper. ptq.dyndns.org> ,
Ken Shan <ken@digitas.ha rvard.edu> wrote:
[color=blue]
> In what sense are "lambda" and "apply" not names?[/color]

Not names from the problem domain, unless the problem domain is
functional programming.

[Ken Shan]

Re: Express What, not How.

Raffael Cavallaro <raffaelcavalla ro@junk.mail.me .not.mac.com> wrote in article <raffaelcavalla ro-8AEE3E.21031117 102003@netnews. attbi.com> in comp.lang.funct ional:[color=blue]
> In article <t76661-316.ln1@proper. ptq.dyndns.org> ,
> Ken Shan <ken@digitas.ha rvard.edu> wrote:[color=green]
> > In what sense are "lambda" and "apply" not names?[/color]
> Not names from the problem domain, unless the problem domain is
> functional programming.[/color]

But in the style of programming that you advocate, as I understand
it, one does not need to give a name to function application from the
problem domain before using it.

--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
"Who needs drugs when we have sex and chocolate?" -- Cory Kerens

[Rayiner Hashem]

Re: Python syntax in Lisp and Scheme

> Obviously, you haven't tried to actually program in Lisp. Getting used[color=blue]
> 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.[/color]
I'd have to concur with this one. Parenthesized-prefix syntax is rather
pretty. What I like is the flexibility in code layout. Ex:

(defun foo (x)
...long function definition here...)

and

int foo(int x)
{
...long function definition here...
}

Are equally natural in their respective syntaxes. However, if you have a
short, simple function:

(defun foo (x) (+ x 2))

is still perfectly natural, while:

int foo(int x) { return x + 2; }

looks a little weird. Most people would write the above similarly to the
first example, which makes it much longer. Block-structured languages in
general tend to suffer from this problem.

[David Rush]

Re: Express What, not How.

On Tue, 14 Oct 2003 22:09:44 GMT, Raffael Cavallaro
<raffaelcavalla ro@junk.mail.me .not.mac.com> wrote:
[color=blue]
> In article <bmh6p4$7b2$1@t erabinaries.xmi ssion.com>,
> Thant Tessman <thant@acm.or g> wrote:
>[color=green]
>> 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.[/color]
....[color=blue]
> It just makes code less readable to use _anonymous_ functions.[/color]

No. It doesn't.

david rush
--
(\x.(x x) \x.(x x)) -> (s i i (s i i))
-- aki helin (on comp.lang.schem e)

[Raffael Cavallaro]

Re: Express What, not How.

Ken Shan <ken@digitas.ha rvard.edu> wrote in message news:<bmq7mh$q7 5$1@news.fas.ha rvard.edu>...
[color=blue]
> But in the style of programming that you advocate, as I understand
> it, one does not need to give a name to function application from the
> problem domain before using it.[/color]

No, one doesn't, as long as that function application is the one place
where the implementation of that bit of functionality needs to be
expressed.

However, if one is using that bit of functionality elsewhere, then it
only constitutes information overload to re-express the implementation
of that functionality yet again in that location. In such a case, that
function application should be named in the one place it is necessary
to express its implementation, and the named version used elsewhere.

Again, it comes down to uniqueness and necessity of exposition. If it
is only going to be expressed once, and there is no loss of clarity,
then use an anonymous function. In this sense anonymous functions are
no different than using the built-ins or primitives of the language.
If this is the place where this bit of functionality needs to be
defined, then, by all means, use anonymous functions to express that
implementation if it is easier.

But if that is not the one and only place where that bit of
functionality is used, then name it. If that is not the one and only
place where that functionality needs to be defined, then don't repeat
the implementation in a half dozen places. Implement it once, name it,
and use the name elsewhere.

[Raffael Cavallaro]

Re: Express What, not How.

Raffael Cavallaro <raffaelcavalla ro@junk.mail.me .not.mac.com> wrote in message news:<raffaelca vallaro-45D8C8.08044117 102003@netnews. attbi.com>...

[color=blue]
> 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.[/color]

Sorry for the typo - that should be "iterative" of course.

[Ken Shan]

Re: Express What, not How.

Raffael Cavallaro <raffael@mediao ne.net> wrote in article <aeb7ff58.03101 82111.6df0b5ab@ posting.google. com> in comp.lang.funct ional:[color=blue]
> Ken Shan <ken@digitas.ha rvard.edu> wrote in message news:<bmq7mh$q7 5$1@news.fas.ha rvard.edu>...[color=green]
> > But in the style of programming that you advocate, as I understand
> > it, one does not need to give a name to function application from the
> > problem domain before using it.[/color]
> No, one doesn't, as long as that function application is the one place
> where the implementation of that bit of functionality needs to be
> expressed.[/color]

The implementation of function application is definitely something
that doesn't need to be expressed in the vast majority of programs.
Moreover, function application is used in many places, far from just
one place. So according to you, I need to find a name for function
application, and not just any name -- it needs to be a name from the
problem domain. But what is a name for function application from the
cash register problem domain?

--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
"Who needs drugs when we have sex and chocolate?" -- Cory Kerens

[Alex Shinn]

Re: Express What, not How.

At Fri, 17 Oct 2003 12:28:14 GMT, Raffael Cavallaro wrote:[color=blue]
>
> 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]

Actually, my problem domain more often than not *is* computer science,
but you could also stick strictly to human language or whatever suits
your fancy.
[color=blue]
> 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.[/color]

I don't see how a framerate is less computer-specific than memoization.
If you want to stay close to the original human language then it would
simply mean the act of running faster than usual.
[color=blue]
> (Note that with-increased-framerate would almost certainly be a
> macro).[/color]

Not necessarily. In Scheme with- forms are almost never macros, and are
almost always passed anonymous functions as arguments.
[color=blue]
> 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.[/color]

You're switching to macros and HOFs when we were talking about anonymous
functions. If you are seriously arguing against the use of HOFs in
general then I think you have a lot to learn. Learn a Lisp (Scheme is
nice and clean) or one of the more functional languages like Haskell.
If you brought macros into the discussion with the idea that any direct
application of an anonymous function should be hidden with a macro then
I question whether your goal is really to achieve more legible code or
is just some irrational bias against anonymous functions?

If you want to program in logic as close to the problem domain as
possible, try a logic programming language like Prolog or CLIPS. You
may be disappointed because even in these languages you have to refer to
low-level details at times. Also you will find that an extremely useful
feature is not only anonymous functions but anonymous facts and rules.
If you want to wait until you can program explicitly in the
highest-level human language then I think you may be even more
disappointed. Firstly because as already mentioned human language makes
heavy use of anonymous functions and unnamed concepts in general. When
possible we combine existing ideas and use their compound forms directly
in speech without giving them a new name. Secondly because human
language is not well suited to exact specifications, which is why when
we try to nail down rules as specifically as possible we end up with
language like legalese.

If you want to tell computers what to do in natural human language,
trusting them to learn what you mean when you're ambiguous (through a
process of correcting them when they guess wrong) then that is an
admirable dream. But it's not programming.

--
Alex

[Raffael Cavallaro]

Re: Express What, not How.

Ken Shan <ken@digitas.ha rvard.edu> wrote in message news:<bmulki$8r g$1@news.fas.ha rvard.edu>...
[color=blue]
> So according to you, I need to find a name for function
> application, and not just any name -- it needs to be a name from the
> problem domain.[/color]

From the problem domain _at_that_level_ . If, at that level, we're
dealing with array bounds checking (assuming, for the moment that
we're using a language that doesn't have that built in), then function
names like check-index, report-invalid-index-error, etc. are names
from the problem domain at that level.

The problem I see with the use of the typical anonymous functional
style is twofold:

1. The same functional idiom is repeated, but not abstracted (i.e.,
not named). This leads to unnecessary "programmer inlining," that is,
writing out the implementation everywhere it is used, rather than
naming it once, and using the name everywhere else.

2. The anonymous functional idioms map well to domains such as
arithmetic, mathematics, and functional programming itself. These same
idioms don't map so well to other domains. The more abstract the
program becomes (that is, the closer it moves to the problem domain,
and the farther it moves from the low level arithmetic and functional
abstractions) the less the anonymous functional idioms will correspond
to the existing concepts and vocabulary of the problem domain.

[Christos TZOTZIOY Georgiou]

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

On 16 Oct 2003 16:37:01 +0200, rumours say that Pascal Bourguignon
<spam@thalassa. informatimago.c om> might have written:
[color=blue][color=green]
>> 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]
>
>Indeed. Had the first lisp been programmed on a 680x0, we would have
>d0 and d1 instead of car and cdr, or worse, had it been done on 8086,
>we would have ax and bx...[/color]

Perhaps on 680x0 they would be ca0 and cd0, or ca0r and cd0r. AFAIK car
stands for contents of address register and cdr for contents of contents
of data register. So, picking register 0 out of 8 (7 if you exclude a7
/ sp) address registers and register 0 out of 8 data registers is just a
choice on this hypothetical subject.

However, I have a suspicion that the "correct" names would be ca0r and
c(a0)r ...
--
TZOTZIOY, I speak England very best,
Ils sont fous ces Redmontains! --Harddix

[David Rush]

Re: Express What, not How.

I've just about decided to killfile this whole thread, but I can't
let this one go by. Two unsubstantiated assertions do not make a bad
programming practice, no matter how hard you try.

On 19 Oct 2003 19:22:04 -0700, Raffael Cavallaro <raffael@mediao ne.net>
wrote:
[color=blue]
> The problem I see with the use of the typical anonymous functional
> style is twofold:[/color]

How much programming have *you* done with anonymous functions? Or is this
complaint based on your esthetic reactions to a series of contrived
examples in usenet posts?
[color=blue]
> 1. The same functional idiom is repeated, but not abstracted (i.e.,
> not named). This leads to unnecessary "programmer inlining," that is,
> writing out the implementation everywhere it is used, rather than
> naming it once, and using the name everywhere else.[/color]

Not by this heavy user of anonymous functions. In fact one of the main
uses I have for anonymous functions is to *avoid* code duplication by
parameterizing over entire categories of functions.

Cut & Paste programming is bad practice in any language. IME, functional
programmers do it *less* often than those from other communities.
[color=blue]
> 2. The anonymous functional idioms map well to domains such as
> arithmetic, mathematics, and functional programming itself. These same
> idioms don't map so well to other domains. The more abstract the
> program becomes (that is, the closer it moves to the problem domain,
> and the farther it moves from the low level arithmetic and functional
> abstractions) the less the anonymous functional idioms will correspond
> to the existing concepts and vocabulary of the problem domain.[/color]

Again, I disagree heartily. I use HO&AFs to enable greater levels of
abstraction since they allow me to abstract *outer* components of
functions while I pass in the site-specific portions. Control-structure-
like
functions are only a fairly trivial example of this kind of thing, but
I have in a mail-processing application 2 functions IF-FROM-LINE (used in
mbox file processing) and RFC822-COLLAPSE-HEADER (used in RFC822 header
processing) which both implement algorithms which are parameterized
by functions. This is vaguely similiar in spirit to the visitor pattern
from OO land, but much more flexible. Both of these functions are used
in multiple contexts where the anonymous functions contextualize the
operations performed under specific conditions in their implemented
algorithms. These operations have (so far) been strictly one-off animals.
In the event that I ever feel a need to re-use one of them I will simply
lift the anonymous function from its original source location, give it
a top-level name et voila - instant reuse.

david rush
--
(\x.(x x) \x.(x x)) -> (s i i (s i i))
-- aki helin (on comp.lang.schem e)

[Raffael Cavallaro]

Re: Express What, not How.

In article <oprxcymd2n3seq 94@news.nscp.ao ltw.net>,
David Rush <drush@aol.ne t> wrote:
[color=blue]
> I have in a mail-processing application 2 functions IF-FROM-LINE (used in
> mbox file processing) and RFC822-COLLAPSE-HEADER (used in RFC822 header
> processing) which both implement algorithms which are parameterized
> by functions. This is vaguely similiar in spirit to the visitor pattern
> from OO land, but much more flexible. Both of these functions are used
> in multiple contexts where the anonymous functions contextualize the
> operations performed under specific conditions in their implemented
> algorithms. These operations have (so far) been strictly one-off animals.[/color]

I think you are in violent agreement with me.

I wrote:[color=blue][color=green]
> > The problem I see with the use of
> > the typical anonymous functional[/color][/color]
^^^^^^^^^[color=blue][color=green]
> > style is twofold:[/color][/color]


1. If-from-line is a _named_ function, not an anonymous function. My
only objection was to _anonymous_ functions replacing named
abstractions, not to functional programming itself.
[color=blue]
> In the event that I ever feel a need to re-use one of them I will simply
> lift the anonymous function from its original source location, give it
> a top-level name et voila - instant reuse.[/color]

2. Which is precisely what I suggested in all of my previous posts.
I.e., if the anonymous function is used more than once, name it, and use
the name.