473,231 Members | 1,884 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,231 software developers and data experts.

merits of Lisp vs Python

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

Dec 8 '06
852 27791
In article
<pa****************************@REMOVE.THIS.cybers ource.com.au>,
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
On Sun, 10 Dec 2006 04:03:25 +0000, Kirk Sluder wrote:
In article
<pa***************************@REMOVE.THIS.cyberso urce.com.au>,
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
So it is good that English restricts the expressiveness and power of the
syntax and grammar. While we're talking English, we can both understand
each other, and in fact people who redefine words and ignore the common
meaning of them are often covering weaknesses in their arguments.
Ohh, can the guy who does discourse analysis for a (meager) living
respond to this?

To start with, English does not restrict the expressiveness and
power of the syntax and grammar.

Really? There are no restrictions whatsoever in English syntax and
grammar? None at all?
Of course I didn't say that: What I said was, "To start with,
English does not restrict the expressiveness and
power of the syntax and grammar. People who use the English language
in specific communities and in specific forms of discourse do. The
key to how this happens occurs on another layer of how language
works which is almost always left out of internet discussions of
language: pragmatics."

As an example of the context-specific nature of pragmatics at work,
if I was your reviewer or editor, I'd reject this manuscript. As a
participant on usenet, I'll just point out that you selectively
quoted the antithesis, and deleted my thesis to argue a straw-man.

Of course there are restrictions, *enforced by users of language in
specific communities.* But the English language is quite malleable,
and includes not only the discourse we are currently engaged in, but
the clipped jargon of internet chat and amateur radio, the
chronically passive discourse of academia, the passionate chants of
protesters, and a wide variety of poetic expression.

This is where wannabe critics of "English grammar" fail to
understand the language they claim to defend, much to the amusement
of those of us who actually do study language as it is, rather than
the mythical eternal logos we want it to be.

Languages are (with some trivial exceptions) human creations. The
laws, rules and restrictions of languages are dynamic and dependent
on community, mode, medium and context. Of course, wannabe
grammarians frequently rise up at this point and say that if such is
the case, then there is nothing to prevent <language of choicefrom
devolving into a babble of incomprehensible dialects. To which the
easy response is that the benefits of conformity to linguistic
communities almost always outweigh the costs of nonconformist
expression.

And if you want to bring this back around to computer languages, the
benefits of conformity to said linguistic communities tends to
outweigh the costs of doing your own thing. (Unless you can make a
convincing argument that "doing your own thing" is superior.)
So, when I say "sits cat rat" it is not only legal English, but you can
tell which animal is sitting on which?
What is "legal" in English depends on the communities in which you
are currently participating. Likely there is some community in which
such clipped discourse is understood and therefore legal. If you are
talking to me, I'd express my lack of comprehension by saying
"Pardon?" and ask you to rephrase.
But I'm belaboring the point. Of course English has restrictions in
grammar and syntax -- otherwise one could write something in Latin or
Thai or Mongolian and call it English. There are RULES of grammar and
syntax in English, which means that there are possible expressions which
break those rules -- hence there are expressions which one can't write in
legal English.
When you make an "illegal" statement in English, exactly who or what
corrects you?

Is it Zeus, the divine Logos, the flying spaghetti monster, some
platonic ideal?

As you can probably tell, this kind of silliness is a bit of a sore
spot for me. So please by all means, do some basic reading of
linguistics before you continue to engage in such silliness. Or at
least learn to properly quote an argument.
Dec 10 '06 #251
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
"Wolfram Fenske" <in***@gmx.netwrites:
>with a couple of macros. I. e. if Common Lisp didn't have CLOS, its
object system, I could write my own as a library and it would be just
as powerful and just as easy to use as the system Common Lisp already
provides. Stuff like this is impossible in other languages.

If Common Lisp didn't have lexically scoped variables (most Lisp
dialects before Scheme didn't have them) then it would be very
difficult to add that with macros.
Alex Mizrahi already took care of that one.
Do you seriously think lexical scoping is the last word in language
features and that there's now nothing left in other languages that
can't straightforwardly be done in CL?
No. My point was more that Lisp is so flexible that it even allows
you to add something as huge as object orientation without requiring a
change to the compiler. What about Aspect-Oriented Programming, for
example? For Java, you need a new compiler/preprocessor, for Lisp, it
can be implemented as a library [1].
Hint: call-with-current-continuation (also known as call/cc).
You're right call/cc is a problem because you basically can't
implement call/cc without having call/cc. I. e. it requires pervasive
changes to the compiler/interpreter if something like it is not
already in there. Still, Scheme--also a Lisp--has call/cc and was
probably the first language to implement it.
I just don't see a non-messy way to simulate Python generators in CL.
They can be done in Scheme using call/cc though.
Scheme is also a Lisp. So?
Take a look sometime at Hughes' paper on "Why Functional Programming
Matters":

http://www.math.chalmers.se/~rjmh/Papers/whyfp.html

The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.
Anything in particular? I'd be surprised if the solutions in Scheme
and CL would differ very much because apart from the Lisp-1/Lisp-2
issue and call/cc, Scheme and CL are not that different.
Footnotes:
[1] <http://common-lisp.net/project/closer/aspectl.html>

--
Wolfram Fenske

A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Dec 10 '06 #252
In article
<pa****************************@REMOVE.THIS.cybers ource.com.au>,
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
That depends. If somebody smart is designing a new programming language,
then no, you get a new programming language.

If somebody not-so-smart is merely hammering the round peg of Lisp into
the square hole of not-quite-Lisp-and-not-quite-anything-else, then yes,
that will be a problem. But apparently, despite the talk of using macros
to implement anything in Lisp, nobody actually does that.
Then what exactly is your argument here?

And BTW:
CL-USER(defun + (a b))
Lock on package COMMON-LISP violated when setting fdefinition of +.
[Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]

While lisp doesn't prohibit such name conflicts, it does mean that
anyone trying it will generate a fair number of errors each time the
definition is compiled.
Perhaps it's because I'm a social scientist and not a programmer by
training, but I find many arguments for *technical* solutions to
*human performance* problems to be rather weak as a general
practice. In some cases, using a very restrictive language may be
the best solution for the problem.

I don't know about you, but I'm not talking about VERY restrictive
languages -- I'm using Python, which isn't very restrictive at all. But
even Lisp has some restrictions -- you can't jump to an arbitrary memory
location and treat whatever random bytes are there as executable code, can
you?
Certainly, and I've even pointed out a few that would mediate
against your claim of incompetent programmers being able to
arbitrarily shadow core functions in a way that is invisible to
anyone else.
Dec 10 '06 #253
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalidwrote:
Kirk Sluder <ki**@nospam.jobsluder.netwrites:
The pythonic way to do this would be to create a class that
implements file-like behaviors:
.....
>
Actually the Python example can lose (e.g. leak a file descriptor
temporarily) if output.write raises an exception (prevents
output.close from running). For this reason Python recently
introduced the "with" statement:

with output as fileLike.open():
output.write("Hello world\n")

Here the file gets closed automatically (by running an exit method in
the fileLike class) when the "with" block exits, whether normally or
through an exception.
Ohhh, shiny!
Dec 10 '06 #254


Steven D'Aprano wrote:
On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:

>>>I know that. It was more of a rhetorical question -- Lispers are either
trying to emphasis the radical nature of what you can do with macros, or
understate it and make them seem just like functions.

Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
to PyCells as part of SoC 2006) is another. The latter is the norm.


If macros' advanced usage is rare,
Hunh? I have tons of them. Of coure at your level of discourse you will
want to know if those are metric tons or...

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Dec 10 '06 #255
Ken Tilton <ke*******@gmail.comwrites:
Steven D'Aprano wrote:
>If that's the best example of what macros can be used for, frankly I'm
unimpressed.

We're shocked.
We are.

(Counting lines? Come on.)
Dec 10 '06 #256


Wolfram Fenske wrote:
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auschreibt:
....
>>Some languages are too expressive.


I disagree. "Too expressive"--what a thing to say.
A sad moment in Usenet discourse... a moment of silence, please.

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Dec 10 '06 #257
Steven D'Aprano wrote:
Oh my god! Lisp can echo STRINGS to the interpreter?
Indeed yes, but that's not exactly what's happening here. (And it's not
necessarily an interpreter, by the way. Some Lisp implementations
compile every expression to machine code and branch to it. Corman Lisp,
for instance, doesn't even contain an interpreter).

My point is not to showcase anything about Lisp, but simply to point
out the irony that in the same paragraph in which you are going on
about Lisp being unreadable compared to human written languages, there
appear pieces of parseable Lisp syntax.
Why didn't somebody somebody tell me that!
The answer to that would be: because your being properly informed for
these kinds of debates is your responsibility, and it is assumed.
!!! That *completely* changes my mind about the language!
If you keep up the mind changing, you can maybe trade up to one that
works in perhaps fewer than twenty transactions. (Think: Kyle
MacDonald).

Dec 10 '06 #258
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
Rightly or wrongly, people fear that Lisp's macros push Lisp closer to
that hypothetical anything-goes language than is healthy. Maybe that's a
Wrongly. And do they? To paraphrase Brian Griffin: "Are you sure it
was people? Are you sure it wasn't...nothing?"
My point isn't whether or not their claims are correct (a "couple" of
macros? really?) but that things like this feed the perception that Lisp
is close to that hypothetical language where anything could be anything.
If anything could be anything, do you really know what (+ 1 2) means
without reading every line of code?
Jesus H Christ. Didn't you just get through talking about how easily
someone can redefine built-ins in Python?
Even something simple like file I/O can be abused. Example: I've seen
Agreed. This is why I've always argued that I/O should never have
been included in programming languages. Too dangerous. And, let's
face it, pretty old-fashioned these days.
(This is an interesting demonstration that any language that allows file
I/O and importing of external program files can always treat functions
as data, even if the language doesn't directly support it. An alternative
would be to keep the strings in memory instead of writing to a module,
then use exec on them instead of importing the module.)
No, it treats code as text. See the difference?
Honest to god, the code really was like that!
Holy cow! How incredible!
Is that an argument against factory functions? Damn straight it is:
they are a powerful tool, and in the hands of morons, they can be
dangerous. Does that mean that languages shouldn't permit higher-order
functions? Not necessarily: all programming tools can be misused, but some
can be misused more easily than others. Power and risk is often a
trade-off, and language designers can't eliminate all risk of stupid
behaviour, but they can design the language to allow whatever level of
risk they believe is acceptable. (E.g. there is no doubt that C's raw
pointers are powerful, but many languages deliberately don't use them.)
Could you please calm down?
The risk of stupid factory functions is small compared to the benefit, but
maybe there is some domain somewhere where the ideal solution is a
language that DOESN'T treat functions as first class objects, deliberately
weakening the language so that a particular class of errors (or stupid
behaviour) just cannot happen. But that language isn't Python.
Could you calm down?
When it comes to Lisp's macros, the perception is that the power is
NB: here, "the" means "Steven D'Aprano's" (the number of meanings
"the" can assume in different contexts is quite surprising).
correspondingly greater, and the risk of abuse even more so. The safe
Don't you get tired of making the same arguments? Because I'm getting
tired of making the same counterpoints.
Dec 10 '06 #259


George Sakkis wrote:
JS******@gmail.com wrote:

>>1. Lisp is the only industrial strength language

^^^^^^^^^^^^^^^^^^^
You keep using that phrase. I don't think it means what you think it
means.
To me in part it means "no one can decide to take away lambda because
they decided they should not have put it in in the first place and then
change their mind and leave it in after I already put a few people on
de-lambdifying our 100kloc system because...", and in part it means
compilation. And it /has/ to have macros. :)

Perhaps it does in some programming language theory research groups.
haha, the same old straw man, Is it not embarrassing to have to resort
to the same defeated argument again and again?
In
the real world, superiority has to do with far more than technical
merits alone, let alone obscure metaprogramming features ...
Metaprogramming by definition cannot be obscure. Metaprogramming means
programming at a higher level. A higher level means "more productive".
More productive is the essence of pragmatism. QED.
...which are
irrelevant to the vast majority of programmers.
You insult them by suggesting they cannot concieve at a higher level.
Mebbe they could if their language aupported it. Yours does not.
I don't know if other lispers
would join you in your feeble attempt to steal a bite from Ruby's
current glory...
Of course we would. You do not get it. The only thing you guys are
bleating about is greater popularity. Now someone is about to eat your
lunch popularity-wise. Live by the poll, die by the poll. And you held
first place for like a week in language geologic time, taken down merely
because...
(mostly thanks to the admirable marketing around the
overhyped Rails framework)
.... a little hype came along? Wow, your fundamental advantage must have
been about zip, and all derived from things unrelated to syntax. <gasp>

, but Ruby is much closer to Python than
either of them is to lisp. In fact, if Python suddenly disappeared,
Ruby would probably be my next stop. Both Ruby and Python are high
level dynamic languages with an emphasis on pragmatic needs, not being
the language of the God(s) (see, I can bring up stupid slogans of
languages too).
As Graham said, if some pretty good programmers are jumping up and down
about X, mebbe you should take a look at X. Even if assholes like me
piss you off. :)

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Dec 10 '06 #260
Ken Tilton wrote:
André Thieme wrote:
>def foo(function, args):
setup(1)
setup(2)
function(args)
cleanup(1)
cleanup(2)

The nice thing in Lisp would now be to save a lambda with the macro.
In Python one would fill the name space with throw away functions that
get called only one time.
That is a deficiency of Python that doesn't exist in modern FPLs like OCaml,
SML, Haskell, F#...
Omigod. Is that what you meant? You think macros are unnecessary because
one could hard-code their expansions as separate functions? And that
would constitute hiding the boilerplate? What happens when the
boilerplate changes? <game over>
He is correct. When the boilerplate changes, you change your HOF.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #261
Steven D'Aprano wrote:
If that's the best example of what macros can be used for, frankly I'm
unimpressed. Yes, I can see some benefit. But I don't see that the benefit
is worth the added complexity. Maybe there are more complex tasks that
macros are better suited for.
You both seem to be trying to implement a pattern match. It would probably
be productive for you to compare Python and Lisp to languages that have
pattern matching.

For example, look at the symbolic simplifier here:

http://www.ffconsultancy.com/free/ocaml/symbolic.html

or the interpreter here:

http://www.ffconsultancy.com/free/oc...terpreter.html

Implementing this kind of stuff in Python is probably a nightmare. At least
you can address Lisp's deficiencies with macros...

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #262
Harry George wrote:
It would probably be fair to say that the more you know
about a variety of languages, the more you appreciate Python.
+1 QOTW

Dec 10 '06 #263
Ken Tilton wrote:
Steven D'Aprano wrote:
>Er, weren't you one of the people claiming that you don't notice parens
when you're reading or writing Lisp code?

Steve, you seem to be doing everything you can to make what is basically
a decent cultural exchange unpleasant...
He has a point. Lispers always say that you can't see the superfluous
parentheses after a month of staring at them, yet you must match them. I do
prefer autoindenting though. Giving whitespace meaning seems like a
second-rate alternative to me...

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #264
"Wolfram Fenske" <in***@gmx.netwrites:
If Common Lisp didn't have lexically scoped variables (most Lisp
dialects before Scheme didn't have them) then it would be very
difficult to add that with macros.

Alex Mizrahi already took care of that one.
I'm not persuaded, I haven't examined his example carefully yet but it
looks like basically a reader hack. Lexical scope in Lisp means among
other things lexical closures and (maybe I'm mistaken) it seemed to me
Alex's example didn't supply that. I'm also unconvinced (so far) of
his description of call/cc as a Lisp macro but that's going to take me
some head scratching.
I just don't see a non-messy way to simulate Python generators in CL.
They can be done in Scheme using call/cc though.

Scheme is also a Lisp. So?
No I don't buy that, you can't say Scheme is Lisp when it suits you to
do so and that it isn't Lisp at other times. I'd say you can map most
of Python's semantics onto Scheme reasonably straightforwardly, but
mapping them to CL is considerably harder, macros or no macros.
http://www.math.chalmers.se/~rjmh/Papers/whyfp.html

The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.

Anything in particular? I'd be surprised if the solutions in Scheme
and CL would differ very much
I took it back, I think you can do it in CL with closures (call/cc not
needed) similar to how it's done in SICP. You could do something
similar in Python but the natural way is with generators.
Dec 10 '06 #265
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
On Sat, 09 Dec 2006 14:57:08 -0500, Bill Atkins wrote:
>Paul Rubin <http://ph****@NOSPAM.invalidwrites:
>>There is just not that much boilerplate in Python code, so there's
not so much need to hide it.

Well, of course there is. There are always going to be patterns in
the code you write that could be collapsed. Language has nothing to
do with it; Lisp without macros would still be susceptible to
boilerplate.

Here's a concrete example:

(let ((control-code (read-next-control-code connection)))
(ecase control-code
(+break+
(kill-connection connection)
(throw :broken-by-client))
(+status+
(send-status-summary connection))
((+noop+ +keep-alive+))))
;; +X+ indicates a constant

Eight lines, excluding the comment, and it doesn't handle the case where
control-code is not one of +break+, +status+, +noop+ or +keep-alive+,
although the ecase macro does. And how many lines of code is ecase?
Doesn't matter because it only has to be written once. For Common
Lisp it's already part of the language. It would of course be bad to
write a macro if pattern comes up only a few times. But that's not
how macros are used.
>All of that boilerplate is handled by the macro. In Python, I
would need to do something like:

control_code = connection.read_next_control_code()
if control_code == +break+:
connection.kill()
throw blah
else if control_code == +status+:
connection.send_status_summary()
else if control_code == +noop+ || control_code == +keep_alive+:
else:
error "CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"
[...]
Saving one line of code, at the expense of having another block of code to
write or understand -- is that really the best example of what macros are
used for in practice? You don't really save writing any boilerplate code,
except for else clause, unless you're claiming that "if" and "elif" is
boilerplate.
No, all the "if control_code == SOME_STATUS:" are boilerplate:

--8<---------------cut here---------------start------------->8---
if control_code == STATUS1:
action_1
else if control_code == STATUS2:
action_2
...
else if control_code == STATUSN:
action_n
else:
Exception(...)
--8<---------------cut here---------------end--------------->8---

The pattern is that one value is compared against several possible
values and depending on which one matches, the appropriate action is
taken. Common Lisp's CASE and ECASE macros and the "switch"
statements of C or Java make this pattern explicit and arguably easier
to recognize. In Python you have to type it out yourself.

[...]
Okay, I'm impressed that ecase can pick up on the four constants being
tested against, and feed their names (rather than merely their values)
into an error message. Python has nothing like that, and if you only have
three or four things to test against, *and* they have names, that could be
a useful thing to do. And if I've understood correctly, that's more a
feature of Lisp's symbols than of macros.

But if you're testing against fifty different values, well, is it really
useful for your error message to list all fifty names? Or do you have
another macro ecase-with-lots-of-tests?
Now you're being silly.

[...]
If that's the best example of what macros can be used for, frankly I'm
unimpressed. Yes, I can see some benefit. But I don't see that the benefit
is worth the added complexity. Maybe there are more complex tasks that
macros are better suited for.


Here's another example. I had to use a database in one of my Python
programs. Everytime I used the database I had write something like
this:

--8<---------------cut here---------------start------------->8---
self.lock.acquire()
try:
connection = sqlite.connect(self.dbFile)
connection.row_factory = dictFactory
try:
# do something with the connection
finally:
connection.close()
finally:
self.lock.release()
--8<---------------cut here---------------end--------------->8---

In Lisp, I could just write a macro "WITH-CONNECTION" that takes the
name of the connection variable and the code for "do something with
the connection" as arguments. Actually, I ended up writing something
like it as a function in Python:

--8<---------------cut here---------------start------------->8---
def withConnection(self, fun):
self.lock.acquire()
try:
connection = sqlite.connect(self.dbFile)
connection.row_factory = dictFactory
try:
return fun(connection)
finally:
connection.close()
finally:
self.lock.release()
--8<---------------cut here---------------end--------------->8---

What would have been the body in the Lisp macro has to be supplied as
function. It's basically a macro, but it still requires more typing
because you have to define a local function eveytime it is used.
Also, there are things you can do with Lisp macros where this
mechanism isn't applicable.

--
Wolfram Fenske

A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Dec 10 '06 #266
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
>Scheme is also a Lisp. So?

No I don't buy that, you can't say Scheme is Lisp when it suits you to
do so and that it isn't Lisp at other times. I'd say you can map most
Quite right.
Dec 10 '06 #267
Jon Harrop <jo*@ffconsultancy.comwrites:
The nice thing in Lisp would now be to save a lambda with the macro.
In Python one would fill the name space with throw away functions that
get called only one time.

That is a deficiency of Python that doesn't exist in modern FPLs like OCaml,
SML, Haskell, F#...
Nothing stops you from re-using the same internal function name in
your Python code, like you might use "i" as a throwaway loop index in
several places in the same function. It's just like in Scheme, the
function is a first class object like an integer.
Dec 10 '06 #268
"Wolfram Fenske" <in***@gmx.netwrites:
In Lisp, I could just write a macro "WITH-CONNECTION" that takes the
name of the connection variable and the code for "do something with
the connection" as arguments. Actually, I ended up writing something
like it as a function in Python:

--8<---------------cut here---------------start------------->8---
def withConnection(self, fun):
self.lock.acquire() # ...
Do you know about Python's "with" statement? You'd define a class for
those db connections, that acquire the lock on entry, and release it
on exit.
Dec 10 '06 #269
Wolfram Fenske wrote:
But seriously... All the interesting features that haven't originated from
Lisp (e. g. OO from Smalltalk) could in turn easily be implemented in Lisp
with a couple of macros.
I was under the impression that CLOS was non-trivial to write. There are
many other interesting features that haven't originated from Lisp (e.g.
pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that cannot
be implemented easily in Lisp because they are intrinsically complicated.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #270
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
>something like:

control_code = connection.read_next_control_code()
if control_code == +break+:
connection.kill()
throw blah
else if control_code == +status+:
connection.send_status_summary()
else if control_code == +noop+ || control_code == +keep_alive+:
else:
error "CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"

Your Python syntax is rather wonky, but that's incidental.
What is wonky about it? The use of +foo+ symbols from the Lisp? Is
there some particular bit of wonkiness you can point out that will
make me think you've done anything but intentionally misunderstand my
post?
Nine lines, including handling the case where control_code is none of the
four constants. Ten if you add the "pass" statement that it actually
needs. And it is completely self-contained, with no external functions or
macros to understand.

Saving one line of code, at the expense of having another block of code to
write or understand -- is that really the best example of what macros are
used for in practice? You don't really save writing any boilerplate code,
except for else clause, unless you're claiming that "if" and "elif" is
boilerplate. Fine, you claim them as boilerplate. I'm going to claim all
those unnecessary brackets as boilerplate.
We're not counting lines here, you goon. We're talking about how
expressive constructs are and how closely they match your concept of
what you want to do. The conditional example is lower-level; you're
talking to the interpreter instead of saying what you want to achieve.
You're having to repeat things because that's what the language asks
of you, instead of describing in a higher-level way what you're
actually doing.
Yes, I know the parser needs them. But as so many people keep telling me,
once you've been writing Lisp code for a month, you don't even notice the
brackets. That makes them unnecessary for the developer, and therefore
something the computer should handle on its own. You've already split
expressions with whitespace, why should you have to use brackets as well?
That's just boilerplate.
This simply means that the parentheses do not stand out. It doesn't
mean that they *literally* cease to become visible (unless I have
perhaps missed out on Lisp enlightenment).

Obviously, this doesn't mean that they are "unnecessary." They are
necessary to give Lisp its regular structure, which 1) makes macros
possible, 2) allows easy movement through and automatic indentation of
code and 3) is aesthetically pleasant, which leads to easier
maintenance. Brackets are no more boilerplate than the significant
whitespace in Python is boilerplate (that is, they're not boilerplate
at all).
Okay, I'm impressed that ecase can pick up on the four constants being
tested against, and feed their names (rather than merely their values)
into an error message. Python has nothing like that, and if you only have
three or four things to test against, *and* they have names, that could be
a useful thing to do. And if I've understood correctly, that's more a
feature of Lisp's symbols than of macros.
But you haven't understood it correctly, of course. The only reason
this works is that the macro is passed the unevaluated code, which
still has the original symbols that the programmer used. It can
insert these into the generated code as it pleases. I feel that
should be clear to someone who claims to know as much Lisp as you do.
But if you're testing against fifty different values, well, is it really
useful for your error message to list all fifty names? Or do you have
another macro ecase-with-lots-of-tests?
Is it really useful? Yes, it is.
If that's the best example of what macros can be used for, frankly I'm
unimpressed. Yes, I can see some benefit. But I don't see that the benefit
is worth the added complexity. Maybe there are more complex tasks that
macros are better suited for.
Did you read the DEFINE-BINARY-CLASS macro I mentioned elsewhere?
Where did you get the notion that ECASE was the best example of where
macros can be used? Why am I responding to another of your absurd
posts?
Dec 10 '06 #271
Bill Atkins <at****@rpi.eduwrites:
maintenance. Brackets are no more boilerplate than the significant
Ack. Of course I mean "parentheses."
Dec 10 '06 #272
Ken Tilton wrote:
George Sakkis wrote:
JS******@gmail.com wrote:

>1. Lisp is the only industrial strength language
^^^^^^^^^^^^^^^^^^^
You keep using that phrase. I don't think it means what you think it
means.

To me in part it means "no one can decide to take away lambda because
they decided they should not have put it in in the first place and then
change their mind and leave it in after I already put a few people on
de-lambdifying our 100kloc system because..."
Funny, coming from the guy with an inclination in discovering straw man
arguments in others. Python 3.0 should be at least a year away from
now, let alone the time of discussions about lambda. If you're changing
a working system based on brainstorms and speculations about a
backwards incompatible version to appear after two years or three, I
can't feel sorry for you :)
, and in part it means
compilation. And it /has/ to have macros. :)
Oh, and I had the vague impression that it was somehow related to
standards about bleeding-edge technologies, such as sockets. But then,
I could be wrong :)
Metaprogramming by definition cannot be obscure. Metaprogramming means
programming at a higher level.
Check.
A higher level means "more productive".
*Segfault* *core dump* *kernel panic* :)

No, it is more productive only if you (and the other 5, 10, 100 people
in your group) can understand, implement, debug, test and maintain code
in that higher level of abstraction.

The rest of the proof is therefore irrelevant ;-)
...which are
irrelevant to the vast majority of programmers.

You insult them by suggesting they cannot concieve at a higher level.
Mebbe they could if their language aupported it. Yours does not.
Actually it does. Metaclasses, descriptors, decorators are some high
level Python concepts. Most people are productive in Python for years
without ever having to write a custom metaclass, or even know their
existence (although a library or framework they use daily might in fact
use all of the above). Ever heard of Zope ? Even though it's written in
Python, it is criticised for its steep learning curve, one main reason
being its high level of abstraction.
I don't know if other lispers
would join you in your feeble attempt to steal a bite from Ruby's
current glory...

Of course we would. You do not get it. The only thing you guys are
bleating about is greater popularity. Now someone is about to eat your
lunch popularity-wise. Live by the poll, die by the poll. And you held
first place for like a week in language geologic time, taken down merely
because...
(mostly thanks to the admirable marketing around the
overhyped Rails framework)

... a little hype came along? Wow, your fundamental advantage must have
been about zip, and all derived from things unrelated to syntax. <gasp>
Well, for one thing we never held the first place anyway. Second, what
appears to be the big boost for Ruby today maybe its death sentence
tomorrow, ending up as a niche language for web apps, like PHP today.
With a large crowd undoubtly, but I bet most Pythonistas would prefer
lower popularity than ending up in a corner of the application
spectrum.
, but Ruby is much closer to Python than
either of them is to lisp. In fact, if Python suddenly disappeared,
Ruby would probably be my next stop. Both Ruby and Python are high
level dynamic languages with an emphasis on pragmatic needs, not being
the language of the God(s) (see, I can bring up stupid slogans of
languages too).

As Graham said, if some pretty good programmers are jumping up and down
about X, mebbe you should take a look at X. Even if assholes like me
piss you off. :)
Change that to "amuse me"; nothing better than a sense of
self-knowledge :) If you mean the same Graham that wrote
http://paulgraham.com/pypar.html, perhaps we don't disagree that much
after all :)

George

Dec 10 '06 #273
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
"Wolfram Fenske" <in***@gmx.netwrites:
[...]
I just don't see a non-messy way to simulate Python generators in CL.
They can be done in Scheme using call/cc though.

Scheme is also a Lisp. So?

No I don't buy that, you can't say Scheme is Lisp when it suits you to
do so and that it isn't Lisp at other times.
OK, I cheated a bit. (Although when I say "Lisp" I don't necessarily
mean Common Lisp. Scheme is also Lisp.) You are right about call/cc
and probably also about lexical variables. I have to modify my
statement from "All the interesting features that haven't originated
from Lisp could easily be implemented in Lisp" to "A lot of the
interesting features ...". Assertions starting with "all" are a
dangerous business because usually someone comes along with a
counter-example. I should have been more careful when I wrote that.

What I meant to say with the two sentences "a lot of 'modern' language
features have originated from Lisp" and "a lot of the interesting
features that haven't originated from Lisp could easily be implemented
in Lisp" was that I believe that Lisp has hit a sweet spot in the
programming language continuum. It must have been right about a lot
of things to still be alive and kicking after all this time.

[...]
http://www.math.chalmers.se/~rjmh/Papers/whyfp.html

The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.

Anything in particular? I'd be surprised if the solutions in Scheme
and CL would differ very much

I took it back,
Sorry, I only noticed that after posting.

--
Wolfram Fenske

A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Dec 10 '06 #274
Wolfram Fenske wrote:
Sure, you can shoot yourself in the foot with macros. But you can do
that in any language of any degree of expressiveness [3]. Come to
think of it, the whole reason why we use high level languages is
because of their expressiveness: We get stuff done faster and
introduce less errors. So "the more expressive, the better," right?
But according to you, there's a point when a language gets "too
expressive". I don't see why.
Is Qi Lisp? There are several problems:

1. Language design is so hard that most people get it wrong (e.g. Python).
What do you do when you find that your proprietary syntax extension was a
bad idea?

2. There is a trade-off between being expressive and sacrificing syntax.
Lisp is very verbose because you must write the AST for your code by hand,
even if you aren't exploiting s-exprs, EVAL and macros.

3. One could argue that every syntax extension in Lisp makes a new language.
So Lisp is a heavily forked language. Is that a good?

Maybe if you're a lone coder and an expert in language design then you can
knock up a DSL and halve your working time using Lisp. In industry, you're
more likely to hire four people with half the expertise each and restrict
them to a well-known C-like syntax.
>Now, if Lispers would say "Oh yes, macros give you great power, and
with great power comes great responsibility. Be careful." then, no
doubt, we'd take you guys more seriously.

Sure, it's a powerful tool but it's not *that* hard to use.
Look at all the threads in c.l.l where people have gotten confused by their
own macros. Look at the unboxing macro that Juho Snellman used to try to
get competitive performance for Lisp on my ray tracer benchmark:

(defmacro def ((name params &body body)
(mname &rest mparams)
(wname &rest wparams))
`(progn
(declaim (inline ,name ,wname))
(defun ,name ,params
(declare (type double-float ,@params))
,@body)
(defmacro ,mname ,(mapcar #'car mparams)
,(loop with inner = (list name)
with body = ``,',inner
with all-names = nil
for (form count) in (reverse mparams)
for names = (loop repeat count collect (gensym))
do
(setf all-names (append all-names names))
(setf body ``(multiple-value-bind ,',(reverse names)
,,form ,,body))
finally
(setf (cdr inner) (reverse all-names))
(return body)))
(defun ,wname ,(mapcar #'car wparams)
(,mname ,@(mapcar #'cadr wparams)))))

Note that this page of magic does something done by the compiler in most
other languages.
Maybe you're afraid of it because that it's something that's unique to
Lisp?
It isn't unique to Lisp. OCaml has camlp4, for example. It is very rarely
used, perhaps because the OCaml community is wary of syntax extensions or
perhaps because it is even harder to use than Lisp's macros.
But IMO the reason for that is not that they're too powerful. IMO it
has mostly to do with the fact that other languages' syntaxes make it
too difficult to implement Lisp-style macros.
I agree. However, the fact that other languages ship with sophisticated
syntax can also be a good thing: it can make them more concise, it can make
them more expressive (e.g. pattern matching).

I get the impression that Lispers use macros when they could use HOFs.
>But we don't hear that -- we hear Lispers going on and on about how
great it is that they can easily redefine every corner of the
language. Do you blame people for *believing them* and imagining
that reading Lisp code is like following some ghostly
will-o-the-wisp across a swamp, where nothing is what it seems and
the landscape is forever shifting?

Come on! You're telling me people don't learn Lisp because they are
afraid of it? Python allows you to redefine built-in functions, as
you said, Ruby allows you to attach new methods to live objects, but
Lisp is simply going too far?
The biggest activation barrier to using Lisp for me is having to write ASTs
for everything by hand. Perhaps it would be a good idea to include an
editor that allowed newbies to use a more familiar syntax and have it
converted to s-exprs for them, so they can see the correspondence and learn
how to write s-exprs themselves?
>Now, if you want to tell me that, despite all the talk, Lisp coders
don't actually create new syntax or mini-languages all that often,
that they just use macros as functions, then the question becomes:
why do you need macros then if you are just using them as functions?
Why not use functions?

Easy because macros are not functions. Functions allow you abstract
functionality, macros allow you abstract syntax.
While that is true, you've provided two examples to back up his point. In
another post you use the example of wrapping try .. finally which can be
done with a HOF instead of a macro. Next, you use the example of COND,
which can also be written as a HOF instead of as a macro:
Look at the examples
above. How would you implement conditional expressions as a function?
Answer: You can't, it's syntax.
That is not true. You can implement conditional expressions without
extending the syntax:

# let rec cond x rules default = match rules with
| [] -default
| (f, e) :: _ when f(x) -e
| _ :: t -cond x t default;;
val cond : 'a -(('a -bool) * 'b) list -'b -'b = <fun>

For example:

# cond 2
[( = ) 1, "one";
( = ) 2, "two";
( = ) 3, "three"]
"neither one, two nor three";;
- : string = "two"

Of course, this is pointless in OCaml because the built-in pattern matcher
is more expressive, powerful and faster than COND:

# match 2 with
| 1 -"one"
| 2 -"two"
| 3 -"three"
| _ -"neither one, two nor three";;
- : string = "two"

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #275
Paul Rubin wrote:
>That is a deficiency of Python that doesn't exist in modern FPLs like
OCaml, SML, Haskell, F#...

Nothing stops you from re-using the same internal function name in
your Python code, like you might use "i" as a throwaway loop index in
several places in the same function. It's just like in Scheme...
It is not "just like in Scheme" if you don't have anonymous functions in
Python.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #276

ta**********@googlemail.com schrieb:
A few months ago, I missed the Condition System most
when using Python, and also lexical scope. However, it is nice to work
with friends, who know Python and not Lisp.)
Could you explain in which way Python lacks lexical scoping?

Dec 10 '06 #277
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
"Wolfram Fenske" <in***@gmx.netwrites:
>In Lisp, I could just write a macro "WITH-CONNECTION" that takes the
name of the connection variable and the code for "do something with
the connection" as arguments. Actually, I ended up writing something
like it as a function in Python:

--8<---------------cut here---------------start------------->8---
def withConnection(self, fun):
self.lock.acquire() # ...

Do you know about Python's "with" statement? You'd define a class for
those db connections, that acquire the lock on entry, and release it
on exit.
Yes, I wrote about it in another post. It was introduced in Python
2.5. And if it hadn't been I'd still have to write code like this.

--
Wolfram Fenske

A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Dec 10 '06 #278
Wolfram Fenske wrote:
It must have been right about a lot of things to still be alive and
kicking after all this time.
No. Fortran and Lisp are just old, not better.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #279
Paul Rubin wrote:
Haskell is pretty neat in that it basically removes things like setq.
That makes possible (for example) very cool simplifications to
concurrent programming. See the paper "Composable memory transactions":

http://research.microsoft.com/~simon.../stm/index.htm

Yeah you could do that with Lisp by writing in a restricted style,
just like you could avoid pointer errors in C++ by writing in a
restricted style. But it's hard for the compiler to guarantee that
your program obeys the restrictions. You could write a language like
Ada or Java that makes a lot of guarantees, but is unexpressive and a
huge pain to program in. You can write a language like Lisp that's
expressive but doesn't make as many guarantees. Interesting problems
in language design arise in writing languages that are expressive AND
make guarantees.
I discovered this recently with F#. Although F# (as a dialect of OCaml) is
impure like Lisp, it does make purely functional programming easy and
provides many purely functional data structures. I translated 15kLOC of
mostly-functional OCaml code into F# and only had to add four locks to make
the whole library concurrent.

That is probably feasible in Lisp but not in Python...

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #280
Jon Harrop <jo*@ffconsultancy.comwrites:
# cond 2
[( = ) 1, "one";
( = ) 2, "two";
( = ) 3, "three"]
"neither one, two nor three";;
- : string = "two"
I'm missing something. Doesn't Ocaml have strict evaluation? That
means if you use function calls instead of string constants in those
values, they all get called. You haven't really done what cond does.
Dec 10 '06 #281
George Sakkis schrieb:
Well, for one thing we never held the first place anyway. Second, what
appears to be the big boost for Ruby today maybe its death sentence
tomorrow, ending up as a niche language for web apps, like PHP today.
With a large crowd undoubtly, but I bet most Pythonistas would prefer
lower popularity than ending up in a corner of the application
spectrum.
Who really wants to write web apps? Web apps are just an excuse for
Pythonistas to write web frameworks.

Dec 10 '06 #282
Jon Harrop <jo*@ffconsultancy.comwrites:
Nothing stops you from re-using the same internal function name in
your Python code, like you might use "i" as a throwaway loop index in
several places in the same function. It's just like in Scheme...

It is not "just like in Scheme" if you don't have anonymous functions in
Python.
Python has anonymous functions (what they can do is somewhat limited
by syntax) but the similarity mentioned with Scheme was about the data
objects. Anyway you don't need to pollute the namespace with lots of
(i.e. more than one) different temporary function name even if you use
non-anonymous functions.
Dec 10 '06 #283
"Kay Schluehr" <ka**********@gmx.netwrites:
A few months ago, I missed the Condition System most
when using Python, and also lexical scope. However, it is nice to work
with friends, who know Python and not Lisp.)

Could you explain in which way Python lacks lexical scoping?
Python has lexical scope but you can't update lexical variables from
scopes other than the innermost or outermost (global) scope. I.e:

def counter():
x = 0
def g():
x += 1
return x
return g

c = counter()
print c()

doesn't do what you'd hope. Yes there are workarounds but they're not
all that satisfactory.
Dec 10 '06 #284
"Wolfram Fenske" <in***@gmx.netwrites:
Yes, I wrote about it in another post. It was introduced in Python
2.5. And if it hadn't been I'd still have to write code like this.
You could do something with decorators that's not too bad. You'd end
up writing:

@withConnection
def some_func():
do_whatever_stuff ()
Dec 10 '06 #285
Jon Harrop <jo*@ffconsultancy.comwrites:
I discovered this recently with F#. Although F# (as a dialect of OCaml) is
impure like Lisp, it does make purely functional programming easy and
provides many purely functional data structures. I translated 15kLOC of
mostly-functional OCaml code into F# and only had to add four locks to make
the whole library concurrent.
The idea of the composable-STM stuff is to not add locks at all, just
mark sections as atomic and the right stuff happens automagically
(i.e. you never have to worry about deadlock), including when you nest
such sections. Its performance also exceeds traditional locking. But
it relies on Haskell's purity.
Dec 10 '06 #286
Paul Rubin wrote:
Jon Harrop <jo*@ffconsultancy.comwrites:
># cond 2
[( = ) 1, "one";
( = ) 2, "two";
( = ) 3, "three"]
"neither one, two nor three";;
- : string = "two"

I'm missing something. Doesn't Ocaml have strict evaluation?
Yes.
That means if you use function calls instead of string constants in those
values, they all get called.
True.
You haven't really done what cond does.
Good point. How about this:

# let rec cond x rules default = match rules with
| [] -default
| f :: t -match f x with
| Some e -e
| None -cond x t default;;
val cond : 'a -('a -'b option) list -'b -'b = <fun>

# cond 2
[(fun n -if n=1 then Some "one" else None);
(fun n -if n=2 then Some "two" else None);
(fun n -if n=3 then Some "three" else None)]
"neither one, two nor three";;
- : string = "two"

The 'Some "one"' is only called if its predicate matched. Anyway, you don't
need macros to write COND and you don't need COND if you have pattern
matching.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #287
Paul Rubin wrote:
Jon Harrop <jo*@ffconsultancy.comwrites:
>I discovered this recently with F#. Although F# (as a dialect of OCaml)
is impure like Lisp, it does make purely functional programming easy and
provides many purely functional data structures. I translated 15kLOC of
mostly-functional OCaml code into F# and only had to add four locks to
make the whole library concurrent.

The idea of the composable-STM stuff is to not add locks at all, just
mark sections as atomic and the right stuff happens automagically
(i.e. you never have to worry about deadlock), including when you nest
such sections. Its performance also exceeds traditional locking. But
it relies on Haskell's purity.
Yes. My point is that I only had to add four locks in 15kLOC of F# code
because my code was almost entirely pure. So F# is a long way towards that
Haskell ideal whilst having many other advantages over Haskell, like
predictable memory usage.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
Dec 10 '06 #288
(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 00:01:34 -0800))
(

PRI'm not persuaded, I haven't examined his example carefully yet but it
PRlooks like basically a reader hack. Lexical scope in Lisp means among
PRother things lexical closures and (maybe I'm mistaken) it seemed to me
PRAlex's example didn't supply that.

lexical scope is pretty low-level concept that affects lot of stuff, so it
requires lot of changes -- we are not extending a language, but build a new
one actually.
we'll have to create object 'lexical environment' and to query it for
variable values instead of just using variable values: var -(query env
'var).
then, we'll need to make closures -- that is a pair of environment and code
itself.
so, it's very close to writting new interpreter -- but it's order of
magnitude easier to write this interpreter via macros than from scratch,
most other language constructs can be reused.
that's the point -- macros allow to implement a language with aprox. same
syntax but different semantics relatively easily.

PR I'm also unconvinced (so far) of his description of call/cc as a Lisp
PRmacro but that's going to take me some head scratching.

there is a chapter about continuations in Paul Graham's "On Lisp".

"Common Lisp doesn't provide call/cc, but with a little extra effort we can
do the same things as we can in Scheme. This section shows how to use macros
to build continuations in Common Lisp programs."

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Dec 10 '06 #289
Jon Harrop <jo*@ffconsultancy.comwrites:
Yes. My point is that I only had to add four locks in 15kLOC of F# code
because my code was almost entirely pure.
But that's like saying you only had to call malloc in 4 different
places, which means dealing with freeing, buffer overruns, etc. As
soon as you use any locks at all, you're susceptable to all the
headaches of dealing with locks. Anyway this is turning into
ML vs. Haskell, maybe an improvement on Lisp vs. Python but still OT.
So F# is a long way towards that Haskell ideal whilst having many
other advantages over Haskell, like predictable memory usage.
F# is pretty similar to ML, right? Hmm. Haskell's memory usage
issues stem more from laziness than purity. One could imagine a
strict Haskell dialect that was still pure (I think ML is heading
in that direction) but that would throw out a lot of Haskell coolness.

Does OCaml support parallel threads at all? I mean using multiple
cpu's simultaneously. I thought it didn't and this was one of the
factors that got me to make the leap into Haskell.
Dec 10 '06 #290
"Alex Mizrahi" <ud******@users.sourceforge.netwrites:
so, it's very close to writting new interpreter -- but it's order of
magnitude easier to write this interpreter via macros than from scratch,
most other language constructs can be reused.
But now you've got an interpreter and you no longer have that Lisp
compiler.
there is a chapter about continuations in Paul Graham's "On Lisp".

"Common Lisp doesn't provide call/cc, but with a little extra effort we can
do the same things as we can in Scheme. This section shows how to use macros
to build continuations in Common Lisp programs."
I think he's mistaken about being able to implement call/cc in full
generality with CL macros in any reasonable way. But it might be
possible to implement enough to do something like Python generators
using lexical closures that one re-enters through some kind of cond
statement selecting the yield point to be continued from.
Dec 10 '06 #291
On Sun, 10 Dec 2006 06:40:46 +0000, Kirk Sluder wrote:
To start with, English does not restrict the expressiveness and
power of the syntax and grammar.

Really? There are no restrictions whatsoever in English syntax and
grammar? None at all?

Of course I didn't say that: What I said was, "To start with,
English does not restrict the expressiveness and
power of the syntax and grammar. People who use the English language
in specific communities and in specific forms of discourse do.
Hang on... are you saying that *people* create languages?

*slaps head*

And here I was thinking that languages fell from the sky like donuts!
Gosh, thank you for explaining that too me. What a fool I must seem!

By the way, that was sarcasm. Of course the English language doesn't exist
in a vacuum. Of course people -- not rocks, not trees, not the Greek
Furies, and especially not the Academie Francaise -- create languages.
And, as an Australian in a world dominated by Americans, I know damn well
that different communities of English speakers use different rules.

*Slightly* different rules. That's why Standard American English and
British English are both English, not different languages like Italian and
German or Korean and Russian.

[snip]
As an example of the context-specific nature of pragmatics at work,
if I was your reviewer or editor, I'd reject this manuscript.
Perhaps you should find out what "manuscript" means before talking about
rejecting one, because what I wrote was most certainly not a manuscript in
any English language I'm aware of.
As a
participant on usenet, I'll just point out that you selectively
quoted the antithesis, and deleted my thesis to argue a straw-man.
Look, I was arguing a really simple point: for communication to occur
between two individuals, both people must agree on a set of rules for the
language that they use to communicate. If they don't have a common
language with agreed upon rules, communication will be feeble and weak, if
not non-existent, or there will be misunderstandings and errors.

Is that so hard to grasp? If you ask for "fire water", by which you
mean whiskey, but I understand to be petrol (gasoline), you're going
to be a very sick person indeed if you drink what I give you.

Of course there are restrictions, *enforced by users of language in
specific communities.* But the English language is quite malleable,
and includes not only the discourse we are currently engaged in, but
the clipped jargon of internet chat and amateur radio, the
chronically passive discourse of academia, the passionate chants of
protesters, and a wide variety of poetic expression.
Did I say it wasn't malleable? You are attacking me for things I never
said.

This is where wannabe critics of "English grammar" fail to
understand the language they claim to defend, much to the amusement
of those of us who actually do study language as it is, rather than
the mythical eternal logos we want it to be.
Ho ho ho, have you ever jumped to a foolish conclusion. You think I'm one
of those tiresome bores who think that just because the ancient Romans
couldn't end a sentence with a preposition, English shouldn't either?
Puh-lease!

Languages are (with some trivial exceptions) human creations. The
laws, rules and restrictions of languages are dynamic and dependent
on community, mode, medium and context. Of course, wannabe
grammarians frequently rise up at this point and say that if such is
the case, then there is nothing to prevent <language of choicefrom
devolving into a babble of incomprehensible dialects. To which the
easy response is that the benefits of conformity to linguistic
communities almost always outweigh the costs of nonconformist
expression.
Yes yes, you're really passionate about language, you have little respect
for grammarians, blah blah blah. None of that has the slightest relevance
to what I was talking about. I'm not denying that languages evolve and
mutate. I'm talking about the simple fact -- and it is a fact -- that two
people must share at least some common linguistic concepts in order
to communicate, and the fewer common constructs they share, the worse
the communication. Languages accomplish that through rules. Yes, the
rules are mere conventions, and can change. They're still rules.

Some languages have very strict rules, some have very flexible rules, but
they all have rules and they all restrict how you use the language.
English has a rule that you turn "programmer" into a plural by adding
"s" to the end. If you decide to drop the -er and add -ing instead, as in
"I hired a team of six programming this week", at best people will do a
double-take and be forced to work out what you mean from context. If you
decide to make the plural of programmer by deleting the first and last
three characters, nobody will have any idea what drugs you are smoking.
[snip]
>So, when I say "sits cat rat" it is not only legal English, but you can
tell which animal is sitting on which?

What is "legal" in English depends on the communities in which you
are currently participating. Likely there is some community in which
such clipped discourse is understood and therefore legal.
Oh yes, the mythical "some community". Nope, sorry, I don't buy it. That's
not legal in any English dialect I've come across, and I've dealt with --
and still do -- English speakers from all over the world. No English
language or dialect typically puts the verb in front of both the object
and subject for present tense expressions. It isn't just *clipped*, the
word order is completely different from English. Didn't you notice that?

But in fact even if there is some obscure dialect of English that would
allow that, that doesn't change my point that there are some constructs
which aren't legal in English (as it exists today). If not "sit cat rat",
something else.

No doubt you can come up with some particular idiomatic phrase in English
that puts the verb first, or a different grammatical construct like the
imperative tense, e.g. "Sit on the rat, cat!". Poetry, in particular,
sometimes uses the verb-subject-object order. But these exceptions merely
emphasis that English, unlike Gaelic, doesn't normally write
verb-subject-object.

A language that was so radically different from all the other English
dialects as to allow "sits cat rat" as a typical construct wouldn't be
English. It might be a pidgin or a creole language. But it won't be
English, not now. In the indefinite future, who knows? I'm not saying that
languages are carved in stone, never to change -- that would be stupid.
But at any one time, languages have rules, even if those rules change over
time, and if two people disagree on those rules, communication is hurt, up
to the point of stopping communication completely.

If you are
talking to me, I'd express my lack of comprehension by saying
"Pardon?" and ask you to rephrase.
And how unfortunate for you that in my local community, "pardon" is the
worst insult imaginable and I punch you in the face.

(See, you aren't the only one that can just invent local communities
with implausible variations of English.)

>But I'm belaboring the point. Of course English has restrictions in
grammar and syntax -- otherwise one could write something in Latin or
Thai or Mongolian and call it English. There are RULES of grammar and
syntax in English, which means that there are possible expressions which
break those rules -- hence there are expressions which one can't write in
legal English.

When you make an "illegal" statement in English, exactly who or what
corrects you?

Is it Zeus, the divine Logos, the flying spaghetti monster, some
platonic ideal?
No. Your peers or your parents or your editor or your teachers correct
you. Or you get a reputation for being "stupid" and people start treating
you as if you were stupid -- maybe they start talk-ing ver-y slow-ly at
you, using baby words. Or people just find it difficult to communicate
with you, or misunderstand what you are trying to say.

There is no law of physics that says that people can't say "Head on my hat
I put". But English speakers just don't do it, and when somebody does,
they are treated as if they aren't speaking English.

But notice that semantics is important -- if I were to say "Head on my
pillow I lay", chances are good that I'd be treated as speaking
poetically, rather than as a non-English speaker. We commonly lay our head
on our pillow, but put our hat on our head.
As you can probably tell, this kind of silliness is a bit of a sore
spot for me. So please by all means, do some basic reading of
linguistics before you continue to engage in such silliness. Or at
least learn to properly quote an argument.
Before patronizing me, do make the effort to understand what I am saying.
Just because you've got valid concerns about ignorant grammarians doesn't
excuse your carelessness. Instead of reading what I actually wrote, you
read into it what you wanted to see: another stupid wanna-be grammarian
who thinks that languages are frozen, static, dead things. You couldn't be
more wrong, and your repeated assumption -- and that's all it was, just an
assumption -- that I know nothing about linguistics is shameful.

Are you man enough to acknowledge your error, or are you going to continue
this ridiculous charade of attacking me for holding views I don't have?
--
Steven.

Dec 10 '06 #292
On 09 Dec 2006 03:16:45 -0800, Paul Rubin
<"http://phr.cx"@nospam.invalidwrote:
"Ramon Diaz-Uriarte" <rd*****@gmail.comwrites:
a) "old-fashioned"? Is that supposed to be an argument? I guess
addition and multiplication are old-fashioned, and so is calculus;so?
I think "old-fashioned" should only carry a negative connotation in
the fashion world, not in programming.

If someone handed you a calculus book written in Latin, you'd probably
find it undesirably old-fashioned too.
I think the "reasoning by analogy" is clearly showing its weakness
here (truth is, it was me who used the analogy to begin with). However
since (and this is no cynicism) I do really respect and find thought
provoking most of what you write,

how is Lisp similar to a calculus book written in Latin (or to the
Latin in the calculus book, or whatever)? What exactly is
"old-fashioned" supposed to mean here, and how does it carry a truly
negative connotation?

R.

P.D. I am only now starting with Lisp, after having written a lot of
Python for the last two years.
--
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz
Dec 10 '06 #293
On Sun, 10 Dec 2006 02:00:02 -0500, Ken Tilton wrote:

Steven D'Aprano wrote:
>On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:

>>>>I know that. It was more of a rhetorical question -- Lispers are either
trying to emphasis the radical nature of what you can do with macros, or
understate it and make them seem just like functions.

Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
to PyCells as part of SoC 2006) is another. The latter is the norm.


If macros' advanced usage is rare,

Hunh? I have tons of them. Of coure at your level of discourse you will
want to know if those are metric tons or...
Stop playing games Ken. You said they were rare. Not me. You. The fact
that you personally make lots of use of the more radical macros doesn't
come into it. As you said, the norm across the wider Lisp community is the
less radical macro, the ones that are basically just functions.

That's what you said -- or are you changing your mind?

--
Steven.

Dec 10 '06 #294
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
Is that an argument against factory functions? Damn straight it is:
they are a powerful tool, and in the hands of morons, they can be
dangerous. Does that mean that languages shouldn't permit
higher-order functions? Not necessarily: all programming tools can
be misused, but some can be misused more easily than others. Power
and risk is often a trade-off, and language designers can't
eliminate all risk of stupid behaviour, but they can design the
language to allow whatever level of risk they believe is
acceptable. (E.g. there is no doubt that C's raw pointers are
powerful, but many languages deliberately don't use them.)
I understand your point, I understand the Java folks. But I think this
point of view is really wrong. The right solution would be to better
train people, to give more good examples or even to not employ those,
who don't grasp it.

You point of view is that of (big) companies: Every developer should
be equal, exchangable. I'm very sure this is only an illusion. And I
think this point of view leads to many failures of (big)
projects. Each project has it's working horse(s) and these are quite
more equal than the others. :)

To deny the good developers, the working horses the power they need
isn't a good idea. Give them all the tools they need and let others
learn from them -- so (nearly) everybody becomes a good to great
developer.

Am I naive? Maybe...
The risk of stupid factory functions is small compared to the
benefit, but maybe there is some domain somewhere where the ideal
solution is a language that DOESN'T treat functions as first class
objects, deliberately weakening the language so that a particular
class of errors (or stupid behaviour) just cannot happen.
And with Lisp macros the good developers may easily create these DSLs
to be used by the not so good developers. :)
That's the perspective of many people, and maybe it is wrong. Maybe
you really need to be immersed in Lisp for a while to see the
advantages of macros.
Yes, I think this perspective is wrong. Some time ago I wondered about
the hype of LinQ -- with Lisp macros it's already there. These things,
embedded languages (like embedded SQL, embedded Prolog, ...) are
really great. I also hate the amount of boilerplate code nesseccary in
Java -- yes, in Python it's muss less, but in Lisp it really vanished.

If you use a really good designed language which don't assume every
programmer to be dumb and equal, yes, maybe macros would be not that
big a bonus. But hey, they are not worse than operator overloading and
the like, so why not include them? (Answer: In most cases it's hard to
add macros because of non-homogenous syntax.) :)

--
Stefan.
Dec 10 '06 #295
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
Look at us: we're all communicating in a common language, English,
and we all agree on syntax and grammar. Now, I could be a lot more
expressive, and language could be a lot more powerful, if I could
define my own language where "You are a poopy-head" was in fact a
detailed and devastatingly accurate and complete explanation for why
Python was a better language than Lisp.
So it is good that English restricts the expressiveness and power of
the syntax and grammar. While we're talking English, we can both
understand each other, and in fact people who redefine words and
ignore the common meaning of them are often covering weaknesses in
their arguments.
Uh, you don't talk often to non-programmers, do you? Talk a bit to
non-programmers about your programming habits, why you prefer which
programming language and so on. Everything in english. How much do
they understand?

Ever talked to skateboarders? Other people of different scenes? They
are creating new, specialized languages every day. Here in Germany a
study was published a little time ago, how few people understand
commercials and their slogans.

Do you know how many jokes work? Yes, by misunderstandings. Why is
this? Because (natural) languages have macros, operator overloading
and all this fuss.

I'm no expert, I not really studied linguistics, but I would say, you
are completley wrong.

--
Stefan.
Dec 10 '06 #296
On Sun, 10 Dec 2006 02:12:29 -0500, Bill Atkins wrote:
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
>Rightly or wrongly, people fear that Lisp's macros push Lisp closer to
that hypothetical anything-goes language than is healthy. Maybe that's a

Wrongly.
That's your opinion, and as an experienced Lisp coder, it is an opinion
worth treating seriously. Nevertheless, a mere denial doesn't constitute
evidence, let alone proof.
And do they? To paraphrase Brian Griffin: "Are you sure it
was people? Are you sure it wasn't...nothing?"
You know, I'm really starting to think that you Lispers -- and I hate to
generalise, but in this case I feel I'm forced to -- have a real problem
here. On the one hand, I keep reading how unfair it is that the rest of
the programming world won't give Lisp a fair go, that all these other
programmers are spreading FUD over Lisp, especially over the macros and
parentheses. And then you come along and imply that nobody is concerned
about Lisp macros.

So which is it? If Lisp is so self-evidently better than every other
language, and if nobody has any fears or concerns with Lisp, why is Lisp a
fringe language? Not as fringe as it was ten years ago, and maybe growing
in popularity, and it is beyond all doubt that Lisp has a lot of influence
amongst language designers, but outside of a few niche areas, its still a
fringe language.
>My point isn't whether or not their claims are correct (a "couple" of
macros? really?) but that things like this feed the perception that Lisp
is close to that hypothetical language where anything could be anything.
If anything could be anything, do you really know what (+ 1 2) means
without reading every line of code?

Jesus H Christ. Didn't you just get through talking about how easily
someone can redefine built-ins in Python?
Yes. But you can't redefine 1+2 in Python, at least not without hacking
the interpreter. Can you redefine (+ 1 2) in Lisp?

>Even something simple like file I/O can be abused. Example: I've seen

Agreed. This is why I've always argued that I/O should never have
been included in programming languages. Too dangerous. And, let's
face it, pretty old-fashioned these days.
Ha ha, I love good sarcasm!

Unfortunately, that isn't good sarcasm.

>(This is an interesting demonstration that any language that allows file
I/O and importing of external program files can always treat functions
as data, even if the language doesn't directly support it. An alternative
would be to keep the strings in memory instead of writing to a module,
then use exec on them instead of importing the module.)

No, it treats code as text. See the difference?
Text is data.

What is the point of your comment? You don't have to argue about every
thing I say, even the ones we agree on. Look again at what I wrote. Is
there anything that gave you the impression that I think that having the
ability to write text to a file and import it is better than actually
supporting functional programming directly?

[snip]
>Is that an argument against factory functions? Damn straight it is:
they are a powerful tool, and in the hands of morons, they can be
dangerous. Does that mean that languages shouldn't permit higher-order
functions? Not necessarily: all programming tools can be misused, but some
can be misused more easily than others. Power and risk is often a
trade-off, and language designers can't eliminate all risk of stupid
behaviour, but they can design the language to allow whatever level of
risk they believe is acceptable. (E.g. there is no doubt that C's raw
pointers are powerful, but many languages deliberately don't use them.)

Could you please calm down?
Huh?
>The risk of stupid factory functions is small compared to the benefit, but
maybe there is some domain somewhere where the ideal solution is a
language that DOESN'T treat functions as first class objects, deliberately
weakening the language so that a particular class of errors (or stupid
behaviour) just cannot happen. But that language isn't Python.

Could you calm down?
Okay, once was funny. Twice is worrying. What exactly is giving you the
idea I need to calm down? Was it the use of reasoning and logic?
Perhaps it was the attempt to be reasonable and moderate and find some
middle ground that we could agree on, or if not agree, at least say "Well,
I disagree with you, but at least I understand where you are coming from"?

>When it comes to Lisp's macros, the perception is that the power is

NB: here, "the" means "Steven D'Aprano's" (the number of meanings
"the" can assume in different contexts is quite surprising).


>
>correspondingly greater, and the risk of abuse even more so. The safe

Don't you get tired of making the same arguments? Because I'm getting
tired of making the same counterpoints.
Dec 10 '06 #297
hg
Bill Atkins wrote:
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>>if Common Lisp didn't have CLOS, its object system, I could write my own
as a library and it would be just as powerful and just as easy to use as
the system Common Lisp already provides. Stuff like this is impossible
in other languages.

Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?

Of course, but you have to realize that Turing-completeness is a
useless concept when comparing languages. C and Python are both
Turing-complete. So: write me some code in each that reads in a line
of text, splits it on spaces and stores the result in an array. Which
would you rather write? Which will be shorter and more easily changed
and straightforwardly grasped in the future?

QED. Turing-completeness is irrelevant when comparing languages.
Take it as a given.
Lisp ? ;-)
Dec 10 '06 #298


Steven D'Aprano wrote:
On Sun, 10 Dec 2006 02:00:02 -0500, Ken Tilton wrote:
>>Steven D'Aprano wrote:
>>>On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:

>I know that. It was more of a rhetorical question -- Lispers are either
>trying to emphasis the radical nature of what you can do with macros, or
>understate it and make them seem just like functions.

Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
to PyCells as part of SoC 2006) is another. The latter is the norm.
If macros' advanced usage is rare,

Hunh? I have tons of them. Of coure at your level of discourse you will
want to know if those are metric tons or...


Stop playing games Ken. You said they were rare. Not me. You. The fact
that you personally make lots of use of the more radical macros doesn't
come into it. As you said, the norm across the wider Lisp community is the
less radical macro, the ones that are basically just functions.

That's what you said -- or are you changing your mind?
No, I simply misapprehended what you wrote, though it was perfectly
clear. You wrote:
If macros' advanced usage is rare, and most usage of macros could be done
by functions, then maybe that explains why so many coders don't miss them.
Maybe my brain misfired because there is so much wrong with that. The
meta-wrong is that clearly you do not understand macros or how they play
out in real applications, but you have climbed up on this soapbox as if
you were an expert on both issues. Like your interview, you are
speculating without basis on what might happen. You do have a good
excuse since GvR does the same.

Here you have a chance to talk with people who program with macros day
in and day out and learn about them, instead you are trying to tell us
how they are used. Does that make a lot of sense? Or do you think we are
lying? :)

Language-transforming macros such as defclass/defmethod (the heart of
CLOS) and my defmodel come along rarely. This does not mean my
applications do not /use/ CLOS extensively. They do. It means I do not
have ten such different language extensions. I have three: defclass,
defmodel, and LOOP. Can you understand that difference? "Used everywhere
because they are so cool" and "just a few such cool tools exist" are not
contradictory.

Does rare mean "who needs it"? Nice try, but obviously not. Well, maybe
not obviously, because not everyone likes OO, but I would not want to
program without defclass or defmodel or even LOOP. The latter is such a
powerful iteration tool it justifies learning the new syntax, which is
also not a problem because I use it all day making it is easy to
remember. (Aside: I /did/ resist learning it for years because of the
different syntax--my loss.)

Recall that this subwar started over someone saying Lisp was able to
"grow" CLOS without changing and have it look like part of the language,
which led you and others to echo GvR and pronounce macros to be
obfuscatory (?). Sorry, no, not in fact. Only in your nightmares.

As for simple macros not being necessary, what they do is clean up the
code, letting the beef stand out more. Obviously people with that
interest do not turn around and create obfuscated code, no matter how
many times you want to FUD that (which seems to be quite a lot <g>).

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Dec 10 '06 #299
In article
<pa****************************@REMOVE.THIS.cybers ource.com.au>,
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
Yes. But you can't redefine 1+2 in Python, at least not without hacking
the interpreter. Can you redefine (+ 1 2) in Lisp?
Not without barreling through error messages about name conflicts.
Dec 10 '06 #300

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
by: Paddy3118 | last post by:
This month there was/is a 1000+ long thread called: "merits of Lisp vs Python" In comp.lang.lisp. If you followed even parts of the thread, AND previously used only one of the languages AND...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.