Python syntax in Lisp and Scheme

[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/lazy-macro-computation.txt

http://www.metaocaml.org/

 

[Edi Weitz]

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

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]

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

 

[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
(e-mail address removed)

 

[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
(e-mail address removed)

 

[Kenny Tilton]

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

 

[Pascal Costanza]

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]

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]

Edi Weitz



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]

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]

Pascal Costanza:



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.

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]

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]

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

 

[Lulu of the Lotus-Eaters]

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

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

 

[Bengt Richter]

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:

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]

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

 

[Kenny Tilton]

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.

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

 

[Kenny Tilton]

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

|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

 

[David Eppstein]

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?

 

[Terry Reedy]

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