Python syntax in Lisp and Scheme

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:
[color=blue]
> Doug Tolton wrote:
>
>[color=green]
>>David Mertz wrote:
>>
>>[color=darkred]
>>>There's something pathological in my posting untested code. One more
>>>try:
>>>
>>> def categorize_join tly(preds, it):
>>> results = [[] for _ in preds]
>>> for x in it:
>>> results[all(preds)(x)].append(x)
>>> return results
>>>
>>>|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]
>>
>>What is your basis for that statement? I personally like the way Lisp
>>does it much better, and I program in both Lisp and Python. With Python
>> it's not immediately apparent if you are passing in a simple variable
>>or a HOF. Whereas in lisp with #' it's immediately obvious that you are
>>receiving or sending a HOF that will potentially alter how the call
>>operates.
>>
>>IMO, that syntax is far clearner.[/color]
>
>
> I think it's about a single namespace (Scheme, Python, Haskell, ...) vs
> CLisp's dual namespaces. People get used pretty fast to having every
> object (whether callable or not) "first-class" -- e.g. sendable as an
> argument without any need for stropping or the like. To you, HOFs may
> feel like special cases needing special syntax that toots horns and
> rings bells; to people used to passing functions as arguments as a way
> of living, that's as syntactically obtrusive as, say, O'CAML's mandate
> that you use +. and not plain + when summing floats rather than ints
> (it's been a couple years since I last studied O'CAML's, so for all I
> know they may have changed that now, but, it IS in the book;-).[/color]
Yeah I'm not a big fan of +. and /. etc. Every operation on floating
point values has to be explicitly specified. You can't even do a 2 +.
3.0. Instead you have do do (float_of_int 2) +. 3.0
I'm not a huge fan of their syntax either. I don't think they've
removed it, because it's in the first chapter of the tutorial on their site.

I also uses HOF's daily, and I don't generally run into problems
specifying that a variable is in fact a function. I like the sharp
quote thouge because it makes it clear that something a little out of
the ordinary is occurring. Honestly though either way is fine with me.
I can see the arguments both ways.

btw CLisp is an implementation of Common Lisp. If you want to shorten
it, it's usually less ambiquous if you use CL.

I'm not going to comment on the dual versus single namespaces, because
that isn't an area I'm very familiar with how Lisp operates.


--
Doug Tolton
(format t "~a@~a~a.~a " "dtolton" "ya" "hoo" "com")

[Thomas F. Burdick]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleax@aleax.it > writes:
[color=blue]
> Kenny Tilton wrote:
>[color=green]
> > Alex Martelli wrote:[color=darkred]
> >> ... I do believe that the
> >> divergence problem has more to do with human nature and sociology, and
> >> that putting in a language features that encourage groups and subgroups
> >> of users to diverge that language ....[/color]
> >
> > Can someone write a nifty Python hack to figure out how many times
> > Lispniks have tried to get Alex to explain how macros are any different
> > than high-order functions or new classes when it comes to The Divergence
> > Problem? I love that we have given it a name, by the way.[/color]
>
> The very 'feature' that was touted by Erann Gat as macros' killer advantage
> in the WITH-CONDITION-MAINTAINED example he posted is the crucial
> difference: functions (HO or not) and classes only group some existing code
> and data; macros can generate new code based on examining, and presumably to
> some level *understanding* , a LOT of very deep things about the code
> arguments they're given.[/color]

Yes! Macros can generate code, and compiler-macros can transform
perfectly ordinary, easy-to-read code into efficient code. Anyone who
has worked in a domain where efficiency matters has run into the
problem most languages have: abstraction *or* efficiency. Custom,
domain-specific transforms are something you can't always expect the
compiler to do. With Lisp, you're not at the mercy of your vendor; if
you know damn well that some readable code A can be transformed into
equivalent, but efficient code B, you can cause it to happen!
[color=blue]
> If all you do with your macros is what you could do with HOF's,[/color]

But you can do more with macros, so there's no point in looking at the
conclusion to this sentance.
[color=blue]
> Oh, and if you're one of those who disapprove of Gat's example feel free
> to say so, but until I hear a substantial majority denouncing it as idiotic
> (and I haven't seen anywhere near this intensity of disapproval for it from
> your camp)[/color]

Of course not, it's a lovely example of one use of macros.
[color=blue]
> I'm quite justifyied in taking it as THE canonical example of a
> macro doing something that is clearly outside the purview of normal
> tools such as functions and classes.[/color]

No, you're not justified at all.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Björn Lindberg:[color=blue]
> Apart from the usual problems with micro benchmarks, there are a few
> things to consider regarding the LOC counts on that site:[/color]

I wasn't the one who pointed out those micro benchmarks. Kenny
Tilton pushed the idea that more concise code is better and that Lisp
gives the most concise code, and that Perl is much more compact
than Python. He suggested I look at some comparisons, so I followed
his suggestion and found that 1) the Lisp code there was not more
succinct than Python and 2) neither was the Perl code.
[color=blue]
> * Declarations. Common Lisp gives the programmer the ability to
> optimize a program by adding declarations to it.[/color]

While OCaml, which has the smallest size, does type inferencing....
[color=blue]
> since the
> micro benchmarks in the shootout are focused on speed of
> execution, and they are so small, all of them contains a lot of
> declarations, which will increase LOC.[/color]

Ahh, good point.
[color=blue]
> * In many languages, any program can be written on a single
> line. This goes for Lisp, ut also for C and other languages.[/color]

Absolutely correct. Both Alex Martellli and I tried to dissuade
Kenny Tilton that LOC was the best measure of succinctness and
appropriateness , and he objected.
[color=blue]
> * I don't think the LOC saving qualities of Lisp is made justice in
> micro benchmarks. The reason Lisp code is so much shorter than the
> equivalent code in other languages is because of the abstractive
> powers of Lisp, which means that the difference will be more
> visible the larger the program is.[/color]

Agreed. I pointed out elsewhere that there has been no systematic
study to show that Lisp code is indeed "so much shorter than the
equivalent code in other languages" where "other languages" include
Python, Perl, or Ruby.

The closest is

http://www.ipd.uka.de/~prechelt/Biblio/

where the example program, which was non-trivial in size
took about 100LOC in Tcl/Rexx/python/perl and about 250LOC
in Java/C/C++.

There was a repeat of that test at

http://www.flownet.com/gat/papers/lisp-java.pdf

which showed that the average Lisp size was 119 LOC and
277 for Java. I eyeballed the numbers, and I'm not sure if
the counts included comments or not, so call it the same.

In any case, it implies you need to get to some serious sized
programs (1000 LOC? 10000LOC? A million?) before
the advantages of Lisp appear to be significant.

That's not saying that they are more obvious in some subdomain.
For that matter, if I want to do hardware I/O on some
memory mapped ports, it's pretty obvious that C is a good
contender for that domain.

So we're left with depending on gut feelings, guided by
(non-rigorous) observation. Eg, observations that Python
does scale to large projects, observations that the people
who will use my code (computational scientists, not
programmers) find Python easier than Lisp and Tcl-style
commands easier than Python :(.

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Rainer Deyke wrote:[color=blue]
> Is portability of code across different language implementations not a[/color]
priority[color=blue]
> for LISP programmers?[/color]

james anderson:[color=blue]
> there are some things which the standard does not cover.[/color]

"The standard" as I understand it, is some document written a decade
ago. Can't a few of you all get together and say "hey, the world's
advanced. Let's agree upon a few new libraries and APIs."?


Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Me:[color=blue][color=green]
> > Note that I did not at all make reference to macros. Your statements
> > to date suggest that your answer to the first is "no."[/color][/color]

Doug Tolton:[color=blue]
> That's not exactly my position, rather my position is that just about
> anything can and will be abused in some way shape or fashion. It's a
> simple fact of working in teams. However I would rather err on the side
> of abstractability and re-usability than on the side of forced[/color]
restrictions.

You are correct. I misremembered "Tolton" as "Tilton" and confused
you with someone else. *blush*

My answer, btw, that the macro preprocessor in C is something
which is useful and too easily prone to misuse. Eg, my original
C book was "C for native speakers of Pascal" and included in
the first section a set of macros like

#define BEGIN {
#define END }

It's not possible to get rid of cpp for C because the language
is too weak, but it is something which takes hard experience to
learn when not to use.

As for a language feature which should never be used. Alex Martelli
gave an example of changing the default definition for == between
floats, which broke other packages, and my favorite is "OPTION
BASE 1" in BASIC or its equivalent in Perl and other langauges.
That is, on a per-program (or even per-module) basis, redefine
the 0 point offset for an array.

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Jon S. Anthony:[color=blue]
> This thing has been debunked for years. No one with a clue takes it
> seriously. Even the author(s) indicate that much of it is based on
> subjective guesses.[/color]

Do you have a reference? And a pointer to something better?

The only one better I know is

http://www.ipd.uka.de/~prechelt/Biblio/jccpprtTR.pdf

which on page 23, Fig. 17, has a mapping from median
work time actual to work time w.r.t the language list.

Of the 6 languages there are two major misorderings.
First, C actually ended up easier to use than Java or C++.
(which is strange since you would think C++ would be
at least as good as C), and second, Tcl actually ends up
much better.

2 of 6 is better than random, so Jones' work can't be
complete bunkum.

Andrew
dalke@dalkescie ntific.com

[Daniel Silva]

Re: Python syntax in Lisp and Scheme

On Thu, 9 Oct 2003, Andrew Dalke wrote:[color=blue]
> Rainer Deyke wrote:[color=green]
> > Is portability of code across different language implementations not a[/color]
> priority[color=green]
> > for LISP programmers?[/color]
>
> james anderson:[color=green]
> > there are some things which the standard does not cover.[/color]
>
> "The standard" as I understand it, is some document written a decade
> ago. Can't a few of you all get together and say "hey, the world's
> advanced. Let's agree upon a few new libraries and APIs."?[/color]

Isn't that what repositories like perl's CPAN are for?

Though it would be nice if everyone agreed on a single, simple
foreign-function interface...

- Daniel

[Jon S. Anthony]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleax@aleax.it > writes:
[color=blue]
> Kenny Tilton wrote:
>[color=green]
> > Alex Martelli wrote:[color=darkred]
> >> ... I do believe that the
> >> divergence problem has more to do with human nature and sociology, and
> >> that putting in a language features that encourage groups and subgroups
> >> of users to diverge that language ....[/color]
> >
> > Can someone write a nifty Python hack to figure out how many times
> > Lispniks have tried to get Alex to explain how macros are any different
> > than high-order functions or new classes when it comes to The Divergence
> > Problem? I love that we have given it a name, by the way.[/color]
>
> The very 'feature' that was touted by Erann Gat as macros' killer advantage
> in the WITH-CONDITION-MAINTAINED example he posted is the crucial
> difference: functions (HO or not) and classes only group some existing code
> and data; macros can generate new code based on examining, and presumably to
> some level *understanding* , a LOT of very deep things about the code
> arguments they're given.[/color]

Are you really this dense? For crying out loud - functions can
generate code as well and just as easily as macros. In fact macros
are just functions anyway so it really should go without saying.

[color=blue]
> If all you do with your macros is what you could do with HOF's,
> it's silly to have macros in addition to HOF's -- just[/color]

No it isn't, because they the mode of _expression_ may be better with
on in context A and better with the other in context B.


[color=blue]
> MTOWTDItis encouraging multiple different approaches to solve any given
> problem -- this, of course, in turn breeds divergence when compared to a[/color]

Actually it breeds better solutions to problems. If you don't
understand this, you will never understand much of anything about good
problem solving.

[color=blue]
> Oh, and if you're one of those who disapprove of Gat's example feel free
> to say so, but until I hear a substantial majority denouncing it as idiotic[/color]

At the moment the only thing I am willing to denounce as idiotic are
your clueless rants.


/Jon

[Erann Gat]

Re: Python syntax in Lisp and Scheme

In article <yShhb.255119$R 32.8279501@news 2.tin.it>, Alex Martelli
<aleax@aleax.it > wrote:
[color=blue]
> then you're really
> designing your own private divergent language (which most posters from
> the Lisp camp appear to assert is an unalloyed good, although admittedly
> far from all).[/color]

FWIW, IMO "designing your own private divergent language" is not an
unalloyed good, but having the *ability* to design your own private
divergent language quickly and easily is. Also, the "private divergent
languages" that most people design using Lisp macros are supersets of
Lisp, so that limits the extent to which divergence happens in practice.

Your position against macros and in favor of HOFs strikes me as being very
similar to those who want to ban model rocketry on the grounds that it is
too dangerous. Yes, macros (and model rockets) can be dangerous. If
you're not careful you can put your eye out with them. But if you are
careful you can do very cool things with them and -- almost as important
-- learn a lot in the process. (And what you learn from Lisp and model
rocketry are deep truths about the world, not a bunch of random kabuki
juju like what you fill your brain with when you learn C++.) This
mindset, that anything that is potentially dangerous ought to be avoided
because it is potentially dangerous, is IMHO a perverse impediment to
progress. There is no reward without risk.

Life is short. It's not hard to produce a reasonable estimate of the
total number of keystrokes that you will be able to execute in a lifetime,
and it's a pretty small number in the grand and glorious scheme of
things. If you have no ambitions beyond writing
yet-another-standard-web-app then macros are not for you. But if your
goals run grander than that then the extra leverage that you get from
things like macros becomes very precious indeed. Once your ambitions pass
a certain point the only option open to you is to teach your computer to
write code for you, because you don't have time to do it yourself. For
example, there is no reason it should take multiple work years to write an
operating system. There is no fundamental reason why one could not build
a computational infrastructure that would allow a single person to write
an operating system from scratch in a matter of days, maybe even hours or
minutes. But such a system is going to have to have a fairly deep
understanding of the relationship of code to hardware. You may want to
write things like:

(define-hardware-type ethernet-controller ...)

or

(define-hardware-standards-hierarchy
(networking
(ethernet
(standard-ethernet
(NE2000 ....))
(fast-ethernet ...)
(gigabit-ethernet ...))
(fddi ...)
(fibre-channel ...)
...)
(mass-storage
(hard-drive
(ide ...)
(scsi ...))

or

(is-a ne2000 standard-ethernet-card)

or

(define-register-layout ...)

God only knows. Only one thing is certain: with macros and readtables you
will be limited only by your imagination. With anything less you will be
limited by something else.

E.

[Lulu of the Lotus-Eaters]

Re: Code block literals

"Vis Mike" <visionary25@_n ospam_hotmail.c om> wrote previously:
|Something like this seems more logical to me:
|for line in file('input.txt ').lines:
| do_something_wi th(line)
|for byte in file('input.txt ').bytes:
| do_something_wi th(byte)

Well, it's spelled slightly differently in Python:

for line in file('input.txt ').readlines():
do_something_wi th(line)

for byte in file('input.txt ').read():
do_something_wi th(byte)

Of course, both of those slurp in the whole thing at once. Lazy lines
are 'fp.xreadlines( )', but there is no standard lazy bytes.

A method 'fp.xread()' might be useful, actually. And taking a good idea
from Dave Benjamin up-thread, so might 'fp.xreadwords( )'. Of course, if
you were happy to write your own class 'File' that provided the extra
iterations, you'd only need to capitalize on letter to get these extra
options.

Yours, Lulu...

--
mertz@ _/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: \_\_\_\_ n o
gnosis _/_/ Postmodern Enterprises \_\_
..cx _/_/ \_\_ d o
_/_/_/ IN A WORLD W/O WALLS, THERE WOULD BE NO GATES \_\_\_ z e

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Thomas F. Burdick:[color=blue]
> With Lisp, you're not at the mercy of your vendor; if
> you know damn well that some readable code A can be transformed into
> equivalent, but efficient code B, you can cause it to happen![/color]

Not at the mercy of your vendor unless you want to use something
which isn't in the standard, like unicode (esp "wide" unicode, >16bit),
regular expressions (esp. regexps of unicode), sockets, or ffi?

But that's just flaming -- ignore me. ;)

Andrew
dalke@dalkescie ntific.com

[Jon S. Anthony]

Re: Python syntax in Lisp and Scheme

"Andrew Dalke" <adalke@mindspr ing.com> writes:
[color=blue]
> Pascal Costanza:[color=green]
> > So what's the result of ("one" - "two") then? ;)[/color]
>
> It's undefined on strings -- a type error. Having + doesn't
> mean that - must exist.[/color]

No, but it makes the semantics odd for an operation named by "+". Of
course it may not be obvious what the semantics should be, but then
the semantics of "hi" + "there" isn't obvious either.

[color=blue]
> (A more interesting question would be to ask what
> the result of "throne" - "one" is. But again, a type error.)[/color]

Why? This seems like a likely candidate for a string -.

[color=blue]
> I understand your point of view. OTOH, it's like when I used to
> work with C. It was standardized, but required that I download
> a slew of packages in order to do things.[/color]

That's why there are _implementation s_. It's odd that the obvious
distinction between "compiler" (or interpreter or whatever) and
"language" is so hard to grasp.

[color=blue]
> appropriate. I know there are good reasons for a standard to
> leave out useful packages, but I know there are good reasons for
> an implementation to include a large number of useful packages.[/color]

Wow, this actually sounds right.

[color=blue]
> Is there a free Lisp/Scheme implementation I can experiment with
> which include in the distribution (without downloading extra
> packages; a "moby" distribution in xemacs speak):
> - unicode
> - xml processing (to some structure which I can use XPath on)
> - HTTP-1.1 (client and server)
> - URI processing, including support for opening and reading from
> http:, file:, and https:
> - regular expressions on both 8-bit bytes and unicode
> - XML-RPC
> - calling "external" applications (like system and popen do for C)
> - POP3 and mailbox processing[/color]

Yes. Allegro CL (ACL) for one.

[color=blue]
> As far as I can tell, there isn't. I'll need to mix and match packages[/color]

You obviously can't "tell" too well.

[color=blue][color=green]
> > (Apart from that, Jython also doesn't provide everything that Python
> > provides, right?)[/color]
>
> No, but there is a good overlap. I believe all of the above are
> supported on both implementations .[/color]

Interaction with Java (to access it's libararies and whatnot) is also
in ACL.

[color=blue]
> Which Common Lisp *distribution* provides the above? I[/color]

One is pointed out above.


/Jon

[Jon S. Anthony]

Re: Python syntax in Lisp and Scheme

"Andrew Dalke" <adalke@mindspr ing.com> writes:

[color=blue]
> Ahhh, so make the language easier for computers to understand and
> harder for intelligent users to use? ;)[/color]

Spoken like a true Python supporter...

/Jon

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Doug Tolton:[color=blue]
> I have this personal theory (used in the non-strict sense here) that
> given enough time any homogenous group will split into at least two
> competing factions.[/color]

Reminds me of Olaf Stapledon's "First and Last Men"? His
civilizations often had two roughtly equal but opposing components.

Also reminds me of learning about the blue eyed/brown eyed
experiment in my sociology class in high school. As it turns out,
I was the only blue-eyed person in the class of 25 or so. :)
[color=blue]
> Over time it seems to me that human
> beings are incapable of remaining as one single cohesive group, rather
> that they will always separate into several competing factions. Or at
> the very least groups will splinter off the main group and form their
> own group.[/color]

Not necessarily "competing" , except in a very general sense. Is
Australian English in competition with Canadian English?
[color=blue]
> However in the opensource world I expect splinters to happen frequently,
> simply because there is little to no organizational control. Even
> Python hasn't been immune to this phenomenon with both Jython and
> Stackless emerging.[/color]

As well as PyPy and (more esoterically) Vyper.

Excepting the last, all have had the goal of supporting the C Python
standard library where reasonably possible. When not possible
(as the case with Jython and various C extensions), then supporting
the native Java libraries.
[color=blue]
> "bristly" ;)[/color]

Ohh! Good word! I had forgotten about it.

Andrew
dalke@dalkescie ntific.com

[Jon S. Anthony]

Re: Python syntax in Lisp and Scheme

"Andrew Dalke" <adalke@mindspr ing.com> writes:
[color=blue][color=green]
> > I don't know how this could be done with 1st, rst or hd, tl respectively.[/color]
>
> Okay, I gave alternatives of "." and ">" instead of "car" and "cdr"
> "." for "here" and ">" for "the rest; over there". These are equally
> composable.
>
> . == car[color=green]
> > == cdr[/color]
> cadr == >.
> caddr == >>.
> cddr == >>[/color]

These "look" worse than the version you're railing against and are
bombs waiting to go off since they have long standing prior meanins
not in any way associated with this type of operation. OTOH, if you
really wanted them, you could define them.

[color=blue]
> Python's reply "There should be one-- and preferably only one --
> obvious way to do it."[/color]

This then is probably the best reason to _not_ use Python for anything
other than the trivial. It has long been known in problem solving
(not just computation) that multiple ways of attacking a problem, and
shifting among those ways, tends to yield the the better solutions.

[color=blue][color=green]
> > The learning curve is steeper, but in the long run you become much more
> > productive.[/color]
>
> Which brings us back to the start of this thread. :)[/color]

If your problems are trivial, I suppose the presumed lower startup
costs of Python may mark it as a good solution medium.

/Jon