Python syntax in Lisp and Scheme

[Lulu of the Lotus-Eaters]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleaxit@yahoo. com> wrote previously:
|Easy pop quiz: of the designers of the languages Perl and Python,
|which one was born in South California, which one in the
|Netherlands... ;-?

Sure... you reckon Larry Wall will move to Amsterdam now?

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:
[color=blue]
> Pascal Costanza:
>[color=green]
>>To put it in a provocative
>>way, Python is a domain-specific language for vaguely defined domains -
>>those that GvR (subconsciously ?) had in mind when he designed the[/color]
> language.
>
> But by the same vein, is not Lisp is a domain-specific language for
> vaguely defined domains? You say that's because Lisp can be used
> for all domains. My continued response is that it's not optimal for all
> domains.[/color]

Yes, we disagree in this regard.
[color=blue]
> (Also, in another post I conjectured that a thoeretical
> quantum computing 'Lisp' may have features for manipulating ensembles
> of structures, in ways inappropriate to current Lisps.)[/color]

I am no expert in quantum computing, so I can't comment on that.
However, you have mentioned that someone has implemented an quantum
extension for Perl - and if that's possible then you can safely bet that
it's also possible in pure Lisp.
[color=blue][color=green]
> > But on the other hand, it is also clear that for unknown domains yet to[/color]
>[color=green]
>>be explored you cannot know the best set of features in advance _by
>>definition_ .[/color]
>
>
> I'll agree with that. So why should Lisp, designed in the 1950s,
> provide the best set of features (and I include more than semantic
> abilities) for situations unenvisioned half a centry later (eg, the concept
> of a "non-professional programmer")?[/color]

I believe that non-professional are more capable than most of us seems
to think. Furthermore, it has been suggested more than once that a valid
working model is that a good Lisp programmer can provide a
domain-specific language for the non-professional programmer. It's very
likely that a DSL matches better the needs of the user than some
restricted general-purpose language.
[color=blue][color=green]
>>Pythonistas are probably driven by the assumption that the language
>>designers have found the best language feature for any task that might
>>arise.[/color]
>
>
> Not at all. When I need language features best found in C (using
> shared memory, or memory mapped I/O), I use C; perhaps called
> from Python.
>
> Were I to need logic programming, I would use at least consider
> Prolog, with bindings like AmziPy or PyProlog, or cousins like
> the Python/CLIPS interface.
>
> (Most of the time though, I need libraries. Eg, calling out to a
> Fortran binary, using 'web services', CORBA, or even, when
> I need browser applet features best found in Java, I use Python
> in its Jython incarnation.)
>
> The phrase I'm trying to push is "multiple language paradigm;
> not multiple paradigm language."[/color]

Ah, but then you need to constantly change the syntax and need to
remember the idiosyncrasies of several languages.

I am not so sure whether this is a good idea. Personally, I prefer not
to think about syntax anymore. It's boring. But that's maybe just me.
[color=blue][color=green]
>>Lispniks are driven by the assumption that there is always the
>>unexpected. No matter what happens, it's a safe bet that you can make
>>Lisp behave the way you want it to behave, even in the unlikely event
>>that something happens that no language designer has ever thought of
>>before.[/color]
>
>
> Ahh, but that assumes that behaviour is the only important thing
> in a language.[/color]

No.
[color=blue]
> I disagree with that assumption, and that difference
> in belief is one of the core reasons this thread has gone on so long.
>
>[color=green]
>>And even if you cannot find a perfect solution in some cases,
>>you will at least be able to find a good approximation for hard
>>problems.[/color]
>
>
> So, umm, how does Lisp handle shared memory? Can I, as
> with C++, say that certain objects/data structures are to be
> allocated from a block of shared memory rather than the standard
> memory arena? What's the way to do I/O through a
> memory-mapped port as on an old DOS machine?
>
> Python cannot do the first, excepted in limited cases using
> extensions written in C/C++, which is also how to handle
> the second case.[/color]

I don't know. I have to ask my vendor. ;-)
[color=blue]
> I'm not saying that Lisp doesn't handle support for allocation
> from multiple arenas; my searches showed many examples
> of using Lisp on shared memory parallel machines. However,
> given my understanding of the language, it isn't obvious how
> that's done. By comparison, C++ has syntax support for
> letting an class define the allocator for an instance and its
> standard templates also take an optional memory allocator.[/color]

If it's only a syntactical issue, then it's a safe bet that you can add
that to the language. Syntax is boring.
[color=blue]
> (Background on when I used C++'s per-class allocators. I
> was writing software for the CAVE, an immersive virtual
> reality system. Each wall of the CAVE is driven by a
> different CPU. The main software driving the visualization
> runs on yet another CPU, and uses high-speed shared
> memory to update the model viewed by the display CPUs.
> It was easy to support; I made a new subclass for the
> model data structures, with an allocator which used the
> shared memory arena. I then made a new container (this
> was pre STL) for storing those objects. A few library
> calls and it was working.)[/color]

Sounds like a possible application for the CLOS MOP.
[color=blue][color=green]
> > This makes them feel safe. (And the large libraries provided[/color]
>[color=green]
>>with Common Lisp and some Scheme systems still cover 90% of the standard
>>tasks.)[/color]
>
>
> Except for my standard tasks in bioinformatics and chemical
> informatics. ;)[/color]

Again, I don't know. You don't really expect me to know everything about
any conceivable field of computer science, do you? ;)
[color=blue][color=green]
>>Yes, it is good thing that a language enables you to "define bombs
>>waiting to go off", because this means that you can also define
>>solutions for your unexpected problems.[/color]
>
>
> Ahh, more analogies. Most people don't work in munitions
> factories. While some are able to make their own bombs,
> most are happy to relegate the task to professionals, and
> depend on still others (the military) to deploy those bombs.[/color]

You have forgotten the stupid politicians who go to war because it makes
them look better on television. No, I don't feel comfortable to depend
on them.

Seriously, I haven't invented this analogy, I have just tried to answer
a rhetorical question by Alex in a non-obvious way. Basically, I think
the analogy is flawed.


Pascal

[prunesquallor@comcast.net]

Re: Python syntax in Lisp and Scheme

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> Lispniks are driven by the assumption that there is always the
> unexpected. No matter what happens, it's a safe bet that you can make
> Lisp behave the way you want it to behave, even in the unlikely event
> that something happens that no language designer has ever thought of
> before. And even if you cannot find a perfect solution in some cases,
> you will at least be able to find a good approximation for hard
> problems. This makes them feel safe. (And the large libraries provided
> with Common Lisp and some Scheme systems still cover 90% of the
> standard tasks.)[/color]

The smartest programmers I know all prefer Lisp (in some form or
another). Given that they agree on very little else, that's saying
a lot.

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Erann Gat wrote:
...[color=blue]
> mindset, that anything that is potentially dangerous ought to be avoided
> because it is potentially dangerous, is IMHO a perverse impediment to
> progress. There is no reward without risk.[/color]

I'm quite happy for you, and all other unreasonable men "without which
there can be no progress", to run all the risks you want, and I'll be happy
to applaud you for your successes -- as long as I don't bear any part of
the costs of your failures.

As for me personally, and for my typical customers, we have lower
appetite for risk: risk is something to be assessed and managed, not
run for its own sake. A risky strategy is one that has higher expected
returns but also higher volatility: and often there's a threshold effect,
where beating the threshold by a lot isn't much more valuable than
beating it by a little, but falling short of the threshold would be a
disaster. Think of delivery dates, for example: delivering a month in
advance is cool, but not really all that important; delivering a month
late may mean the firm has gone bust in the meantime for lack of
the application it was counting on. I prefer software development
strategies that let me be reasonably sure I can deliver within the
deadline, rather than ones that may, with luck, allow spectacularly
earlier delivery... but risk missing the crucial deadline. I'm a lucky
man, but part of the secret of luck is not pushing it;-).

You seem to be saying that the technologies you prefer are suited
only for cases in which, e.g., running substantial risks of missing the
deadline IS to be considered acceptable. Presumably, that must be
because no safer technology stands a good chance of delivering
reliably -- i.e., cases in which you're pushing the envelope, and the
state of the art. Been there, done that, decided that research does
not float my boat as well as working in the trenches, in software
production environments. I like delivering good working programs
that people will actually use, thus making their life a little bit better.

In other words, I'm an engineer, not a scientist. Scientists whose
goals are not the programs they write -- all those for whom the
programs are mere tools, not goals in themselves -- tend to feel
likewise about programming and other technologies that support
their main work but are secondary to it, though they may have
ambitions as burning as you wish in other, quite different areas.

So, maybe, your favourite technologies are best for research in
computer science itself, or to develop "artificial intelligence" programs
(has the term gone out of fashion these days?) and other programs
pushing the envelope of computer science and technology -- and
mine are best for the purpose of delivering normal, useful, working
applications safely and reliably. If this is true, there is surely space
for both in this world.
[color=blue]
> things. If you have no ambitions beyond writing
> yet-another-standard-web-app then macros are not for you. But if your[/color]

Not necessarily web, of course; and generally not standard, but rather
customized for specific customers or groups thereof. But yes, I basically
feel there's a huge unfilled demand for perfectly normal applications,
best filled by technologies such as Python, which, I find, maximize the
productivity of professional programmers in developing such apps and
frameworks for such apps, AND empower non-professional programmers
to perform some of their own programming, customizing, and the like.
My only, very modest ambition is to make some people's lives a little
better than they would be without my work -- I think it's a realistic goal,
and that, a little bit at a time, I am in fact achieving some part of it.

So, general macros in a general-purpose language are not for me, nor for all
those who feel like me -- not for _production_ use, at least, though I do
see how they're fun to play with.

[color=blue]
> example, there is no reason it should take multiple work years to write an
> operating system. There is no fundamental reason why one could not build
> a computational infrastructure that would allow a single person to write
> an operating system from scratch in a matter of days, maybe even hours or
> minutes. But such a system is going to have to have a fairly deep[/color]

So why don't you do it? As I recall, the "lisp machines"' operating
systems, written in lisp, were nothing lilke that -- were the lisp
programmers working for lisp machine companies so clueless as not to
see the possibilities that, to you, are so obvious? And yet I had the
impression those companies hired the very best they could find, the stardom
of lispdom. Well then, there's your chance, or that of any other lisper
who agrees with you -- why don't you guys go for it and *show* us, instead
of making claims which some of us might perhaps think are empty boasts...?


Alex

[prunesquallor@comcast.net]

Re: Python syntax in Lisp and Scheme

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> Andrew Dalke wrote:
>[color=green]
>> Pascal Costanza:
>>[color=darkred]
>>>To put it in a provocative
>>>way, Python is a domain-specific language for vaguely defined domains -
>>>those that GvR (subconsciously ?) had in mind when he designed the[/color]
>> language.
>> But by the same vein, is not Lisp is a domain-specific language for
>> vaguely defined domains? You say that's because Lisp can be used
>> for all domains. My continued response is that it's not optimal for all
>> domains.[/color]
>
> Yes, we disagree in this regard.
>[color=green]
>> (Also, in another post I conjectured that a thoeretical
>> quantum computing 'Lisp' may have features for manipulating ensembles
>> of structures, in ways inappropriate to current Lisps.)[/color]
>
> I am no expert in quantum computing, so I can't comment on
> that. However, you have mentioned that someone has implemented an
> quantum extension for Perl[/color]

That doesn't sound too hard. Perl is *already* fairly non-deterministic.
[color=blue]
> Personally, I prefer not to think about syntax anymore. It's
> boring. But that's maybe just me.[/color]

Agreed. It's a solved problem.

[Robin Becker]

Re: Python syntax in Lisp and Scheme

In article <gGWhb.200390$h E5.6777507@news 1.tin.it>, Alex Martelli
<aleaxit@yahoo. com> writes[color=blue]
>Jon S. Anthony wrote:
> ...[color=green]
>> bombs waiting to go off since they have long standing prior meanins
>> not in any way associated with this type of operation. OTOH, if you
>> really wanted them, you could define them.[/color]
>
>Is it a good thing that you can define "bombs waiting to go off"?
>
>[color=green][color=darkred]
>>> Python's reply "There should be one-- and preferably only one --
>>> obvious way to do it."[/color]
>>
>> This then is probably the best reason to _not_ use Python for anything
>> other than the trivial. It has long been known in problem solving
>> (not just computation) that multiple ways of attacking a problem, and
>> shifting among those ways, tends to yield the the better solutions.[/color]
>
>One, and preferably only one, of those ways should be the obvious one,
>i.e., the best solution. There will always be others -- hopefully they'll
>be clearly enough inferior to the best one, that you won't have to waste
>too much time considering and rejecting them. But the obvious one
>"may not be obvious at first unless you're Dutch".
>
>The worst case for productivity is probably when two _perfectly
>equivalent_ ways exist. Buridan's ass notoriously starved to death in
>just such a worst-case situation; groups of programmers may not go
>quite as far, but are sure to waste lots of time & energy deciding.
>
>
>Alex
>[/color]
I'm not sure when this concern for the one true solution arose, but even
GvR provides an explicit example of multiple ways to do it in his essay

http://www.python.org/doc/essays/list2str.html

Even in Python there will always be tradeoffs between clarity and
efficiency.
--
Robin Becker

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Kenny Tilton wrote:
...[color=blue][color=green]
>> The very 'feature' that was touted by Erann Gat as macros' killer
>> advantage in the WITH-CONDITION-MAINTAINED example he posted is the
>> crucial difference: functions (HO or not) and classes only group some
>> existing code and data; macros can generate new code based on examining,
>> and presumably to some level *understanding* , a LOT of very deep things
>> about the code arguments they're given.[/color]
>
> Stop, your scaring me. You mean to say there are macros out there whose
> output/behavior I cannot predict? And I am using them in a context where
> I need to know what the behavior will be? What is wrong with me? And
> what sort of non-deterministic macros are these, that go out and make
> their own conclusions about what I meant in some way not documeted?[/color]

Let's start with that WITH-CONDITION-MAINTAINED example of Gat. Remember
it? OK, now, since you don't appear to think it was an idiotic example,
then SHOW me how it takes the code for the condition it is to maintain and
the (obviously very complicated: starting a reactor, operating the reactor,
stopping the reactor -- these three primitives in this sequence) program
over which it is to maintain it, and how does it modify that code to ensure
this purpose. Surely, given its perfectly general name, that macro does not
contain, in itself, any model of the reactor; so it must somehow infer it
(guess it?) from the innards of the code it's analyzing and modifying.

Do you need to know what the behavior will be, when controlling a reactor?
Well, I sort of suspect you had better. So, unless you believe that Gat's
example was utterly idiotic, I think you can start explaining from right
there.
[color=blue]
> I think the objection to macros has at this point been painted into a
> very small corner.[/color]

I drastically disagree. This is just one example, that was given by one of
the most vocal people from your side, and apparently not yet denounced
as idiotic, despite my asking so repeatedly about it, so presumably agreed
with by your side at large. So, I'm focusing on it until its import is
clarified. Once that is done, we can tackle the many other open issues.

For example, the fact that Gat himself says that if what I want to write
are normal applications, macros are not for me: only for those who want
to push the boundaries of the possible are they worthwhile. Do you think
THAT is idiotic, or wise? Please explain either the reason of the drastic
disagreements in your camp, or why most of you do keep trying pushing
macros (and lisp in general) at those of us who are NOT particularly
interested in "living on the edge" and running big risks for their own sake,
accordingly to your answer to the preceding question, thanks.

"Small corner"?! You MUST be kidding. Particularly given that so many
on your side don't read what I write, and that you guys answer the same
identical questions in completely opposite ways (see below for examples
of both), I don't, in fact, see how this stupid debate will ever end, except
by exhaustion. Meanwhile, "the objection to macros" has only grown
larger and larger with each idiocy I've seen spouted in macros' favour,
and with each mutual or self-contradiction among the macros' defenders.

[color=blue][color=green]
>> ...If all you do with your macros is what you could
>> do with HOF's, it's silly to have macros in addition to HOF's[/color]
>
> There is one c.l.l. denizen/guru who agrees with you. I believe his[/color]

....and there's another who has just answered in the EXACTLY opposite
way -- that OF COURSE macros can do more than HOF's. So, collectively
speaking, you guys don't even KNOW whether those macros you love so
much are really necessary to do other things than non-macro HOFs allow
(qualification inserted to try to divert the silly objection, already made
by others on your side, that macros _are_ functions), or just pretty things
up a little bit. Would y'all mind coming to some consensus among you
experienced users of macros BEFORE coming to spout your wisdom over
to us poor benigthed non-lovers thereof, THANKYOUVERYMUC H...?
[color=blue][color=green]
>> far from all). This is far from the first time I'm explaining this, btw.[/color]
>
> Oh. OK, now that you mention it I have been skimming lately.[/color]

In this case, I think it was quite rude of you to claim I was not answering
questions, when you knew you were NOT READING what I wrote.


As you claim that macros are just for prettying things up, I will restate
(as you may not have read it) one of the many things I've said over and
over on this thread: I do not believe the minor advantage of prettying
things up is worth the complication, the facilitation of language
divergence between groups, and the deliberate introduction of multiple
equivalent ways to solve the same problem, which I guess you do know
I consider a bad thing, one that impacts productivity negatively.


Alex

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

prunesquallor@c omcast.net:[color=blue]
> The smartest programmers I know all prefer Lisp (in some form or
> another). Given that they agree on very little else, that's saying
> a lot.[/color]

Guess you don't know Knuth.

The smartest programmers I know prefer Python. Except Guido.
He write a lot of C.

Bias error? On whose side?

The smartest people I know aren't programmers. What does
that say?

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Me:[color=blue][color=green]
> > My continued response is that [Lisp is] not optimal for all
> > domains.[/color][/color]

Pascal Costanza:[color=blue]
> Yes, we disagree in this regard.[/color]

*Shrug* The existence of awk/perl (great for 1-liners on the
unix command-line) or PHP (for simple web programming) or
Mathematica (for symbolic math) is strong enough evidence for
me to continue to disagree.

Pascal Costanza:[color=blue]
> However, you have mentioned that someone has implemented an quantum
> extension for Perl - and if that's possible then you can safely bet that
> it's also possible in pure Lisp.[/color]

The fact that all computing can be programmed in Turing Machine
Language doesn't mean TML is the optimal programming language.

The fact that there is perl code for emulating *some* quantum
programming means that Lisp can handle that subset. It doesn't mean
that people have fully explored even in Lisp what it means to do all
of quantum computing.
[color=blue]
> Furthermore, it has been suggested more than once that a valid
> working model is that a good Lisp programmer can provide a
> domain-specific language for the non-professional programmer. It's very
> likely that a DSL matches better the needs of the user than some
> restricted general-purpose language.[/color]

Another *shrug* And a good C programmer can provide a
domain-specific language for the non-professional programmer.

Any good Python programmer could make an implementation
of a Lisp (slow, and not all of GC Lisp, but a Lisp) in Python, like

import lisp
def spam(distance):
"""(time_to_fal l 9.8 distance)"""
spam = lisp.convert(sp am)

def time_to_fall(g, distance):
print "The spam takes", (2.0*distance/g)**(0.5), "seconds to fall"

print spam(10)
[color=blue]
> Ah, but then you need to constantly change the syntax and need to
> remember the idiosyncrasies of several languages.[/color]

Yup. Just like remembering what macros do for different domains.
I firmly believe people can in general easily handle much more
complicated syntax than Lisp has. There's plenty of room to
spare in people's heads for this subject.
[color=blue]
> I am not so sure whether this is a good idea. Personally, I prefer not
> to think about syntax anymore. It's boring. But that's maybe just me.[/color]

wave equation vs. matrix approach
Newtownian mechanics or Lagrangian
measure theory or non-standard analysis
recursive algorithms vs. iterative ones
travelling salesman vs. maximum clique detection

Each is a pair of different but equivalent ways of viewing the same
problem. Is the difference just syntax?
[color=blue][color=green]
> > Ahh, but that assumes that behaviour is the only important thing
> > in a language.[/color]
>
> No.[/color]

Thank you for your elaboration. You say the driving force is the
ability to handle unexpected events. I assumed that means you need
new styles of behaviour.
[color=blue]
> If it's only a syntactical issue, then it's a safe bet that you can add
> that to the language. Syntax is boring.[/color]

Umm... Sure. C++ can be expressed as a parse tree, and that
parse tree converted to an s-exp, which can be claimed to be
a Lisp; perhaps with the right set of macros.

Still doesn't answer my question on how nicely Lisp handles
the 'unexpected' need of allocating objects from different
memory arenas.
[color=blue]
> Sounds like a possible application for the CLOS MOP.[/color]

Or any other language's MOP.
[color=blue]
> Seriously, I haven't invented this analogy, I have just tried to answer
> a rhetorical question by Alex in a non-obvious way. Basically, I think
> the analogy is flawed.[/color]

Then the right solution is to claim the analogy is wrong, not
go along with it as you did. ;)

Andrew
dalke@dalkescie ntific.com

[Peter Seibel]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleaxit@yahoo. com> writes:
[color=blue]
> Jon S. Anthony wrote:[/color]

[snip]
[color=blue][color=green][color=darkred]
> >> If all you do with your macros is what you could do with HOF's,
> >> it's silly to have macros in addition to HOF's -- just[/color]
> >
> > No it isn't, because they the mode of _expression_ may be better with
> > on in context A and better with the other in context B.[/color]
>
> I care about "mode of expression" when I write poetry. When I write
> programs, I care about simplicity, clarity, directness.[/color]

Right on. Then you should dig (Common Lisp-style) macros because they
give programmers tools it *increase* simplicity, clarity, and
directness. That's the point. They are just another tool for creating
useful abstractions--in this case a way to abstract syntax that would
otherwise be repetitive, obscure, or verbose so the abstracted version
is more clear.

If for some reason you believe that macros will have a different
effect--perhaps decreasing simplicity, clarity, and directness then
I'm not surprised you disapprove of them. But I'm not sure why you'd
think they have that effect.

I don't know if you saw this example when I originally posted it since
it wasn't in c.l.python so I'll take the liberty of quoting myself.
(Readers who've been following this thread in c.l.lisp, c.l.scheme, or
c.l.functional have probably already seen this:

In request for examples of macros that allow one to write
less-convoluted code I give this example:

Okay, here's an example of a couple macros I use all the time. Since I
write a lot of unit tests, I like to have a clean syntax for
expressing the essence of a set of related tests. So I have a macro
DEFTEST which is similar to DEFUN except it defines a "test function"
which has some special characteristics . For one, all test functions
are registered with the test framework so I can run all defined tests.
And each test function binds a dynamic variable to the name of the
test currently being run which is used by the reporting framework when
reporting results. So, to write a new test function, here's what I
write:

(deftest foo-tests ()
(check
(= (foo 1 2 3) 42)
(= (foo 4 5 6) 99)))

Note that this is all about the problem domain, namely testing. Each
form within the body of the CHECK is evaluated as a separate test
case. If a given form doesn't evaluate to true then a failure is
reported like this which tells me which test function the failure
was in, the literal form of the test case and then the values of any
non-literal values is the function call (i.e. the arguments to = in
this case.)

Test Failure:

Test Name: (FOO-TESTS)
Test Case: (= (FOO 1 2 3) 42)
Values: (FOO 1 2 3): 6


Test Failure:

Test Name: (FOO-TESTS)
Test Case: (= (FOO 4 5 6) 99)
Values: (FOO 4 5 6): 15


So what is the equivalent non-macro code? Well the equivalent code
to the DEFTEST form (i.e. the macro expansion) is not *that* much
more complex--it just has to do the stuff I mentioned; binding the
test name variable and registering the test function. But it's
complex enough that I sure wouldn't want to have to type it over and
over again each time I write a test:

(progn
(defun foo-tests ()
(let ((test::*test-name*
(append test::*test-name* (list 'foo-tests))))
(check
(= (foo 1 2 3) 42)
(= (foo 4 5 6) 99))))
(eval-when (:compile-toplevel :load-toplevel :execute)
(test::add-test 'foo-tests)))

But the real payoff comes when we realize that innocent looking CHECK
is also a macro. Thus to see what the *real* benefit of macros is we
need to compare the original four-line DEFTEST form to what it expands
into (i.e. what the compiler actually compiles) when all the
subsidiary macros are also expanded. Which is this:

(progn
(defun foo-tests ()
(let ((test::*test-name*
(append test::*test-name* (list 'foo-tests))))
(let ((#:end-result356179 t))
(tagbody
test::retry
(multiple-value-bind (#:result356180 #:bindings35618 1)
(let ((#:g356240 (foo 1 2 3)) (#:g356241 42))
(values (= #:g356240 #:g356241)
(list (list '(foo 1 2 3) #:g356240))))
(if #:result356180
(signal
'test::test-passed
:test-name test::*test-name*
:test-case '(= (foo 1 2 3) 42)
:bound-values #:bindings35618 1)
(restart-case
(signal
'test::test-failed
:test-name test::*test-name*
:test-case '(= (foo 1 2 3) 42)
:bound-values #:bindings35618 1)
(test::skip-test-case nil)
(test::retry-test-case nil (go test::retry))))
(setq #:end-result356179
(and #:end-result356179 #:result356180) )))
(tagbody
test::retry
(multiple-value-bind (#:result356180 #:bindings35618 1)
(let ((#:g356242 (foo 4 5 6)) (#:g356243 99))
(values (= #:g356242 #:g356243)
(list (list '(foo 4 5 6) #:g356242))))
(if #:result356180
(signal
'test::test-passed
:test-name test::*test-name*
:test-case '(= (foo 4 5 6) 99)
:bound-values #:bindings35618 1)
(restart-case
(signal
'test::test-failed
:test-name test::*test-name*
:test-case '(= (foo 4 5 6) 99)
:bound-values #:bindings35618 1)
(test::skip-test-case nil)
(test::retry-test-case nil (go test::retry))))
(setq #:end-result356179
(and #:end-result356179 #:result356180) )))
#:end-result356179)))
(eval-when (:compile-toplevel :load-toplevel :execute)
(test::add-test 'foo-tests)))


Note that it's the ability, at macro expansion time, to treat the code
as data that allows me to generate test failure messages that contain
the literal code of the test case *and* the value that it evaluated
to. I could certainly write a HOF version of CHECK that accepts a list
of test-case-functions:

(defun check (test-cases)
(dolist (case test-cases)
(if (funcall case)
(report-pass case)
(report-failure case))))

which might be used like:

(defun foo-tests ()
(check
(list
#'(lambda () (= (foo 1 2 3) 42))
#'(lambda () (= (foo 4 5 6) 99)))))


But since each test case would be an opaque function object by the
time CHECK sees it, there'd be no good option for nice reporting from
the test framework. (Of course I'm no functional programming wizard so
maybe there are other ways to do it in other languges (or even Lisp)
but for me, the test, no pun intended, is, is the thing I have to
write to define a new test function much more complex than my original
DEFTEST form?


-Peter

--
Peter Seibel peter@javamonke y.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Doug Tolton wrote:
...[color=blue]
> I can understand and respect honest differences of opinions. I too[/color]

If so, that makes you an exception in the chorus of lispers who are
screaming against my alleged idiocy and cluelessness (though I
seem to remember you also did, but I may be confusing people "on
your side" -- it's been a LONG and unpleasant thread).
[color=blue]
> believe that causes of divergence are largely sociological. I differ
> though in thinking that features which allow divergence will necessarily
> result in divergence.[/color]

I don't think it _necessarily_ will, just that it increases probability by
enough to be a concausal factor.

[color=blue]
> I have this personal theory (used in the non-strict sense here) that
> given enough time any homogenous group will split into at least two
> competing factions. This "theory" of mine had it's roots in a nice[/color]

Unless there's a common enemy who's perceived to be threatening
enough to the whole group -- this is probably the single strongest
unifying factor ("united we stand, divided we fall" -- if people are scared
enough to believe this, they may then remain united).

But the amount of time and other external factors needed to eventually
promote divergence varies with internal factors -- and in cases where
technology plays a key role in the group, then the details of that
technology matter. Some technological aspects intrinsically promote
convergence and cooperation and thus may help counteract sociological
factors working in the other direction -- other technological aspects
facilitate divergence. "In the long run we're all dead" (Keynes), so if
the time needed for divergence is not enough, divergence will not
happen within the group's lifetime;-).

[color=blue]
> However in the opensource world I expect splinters to happen frequently,
> simply because there is little to no organizational control. Even[/color]

And you would be wrong: forks are much less frequent than your theory
predicts. Read some Eric Raymond to understand this, he's got good
ideas about these issues.
[color=blue]
> Python hasn't been immune to this phenomenon with both Jython and
> Stackless emerging.[/color]

Neither of them is a fork, nor a splinter, nor a split. Jython tracks the
Python standard (as much as it can with far too few core developers)
and the Python standard has been modified to allow Jython to conform
on some points (e.g. timing of garbage collection). Stackless has been
rewritten to become a patch as small as possible on standard Python.

And if you look at the people involved, well, I've seen Samuele Pedroni
(Jython's chief maintainer), Christian Tismer (Mr Stackless), Guido van
Rossum (Mr Python) -- and many others, including yours truly -- sitting in
the same room hacking at the same project during a "sprint" this summer.
And happily guzzling beer and/or wine at the barbecue afterwards, of course.

There's just no "splinter" effect in all of this -- just different
technology needs (e.g. a need to cooperate with some Java libraries
seamlessly), requiring different implementations of the same language,
Python.
[color=blue]
> Some people want power and expressiveness. Some people want control and
> uniformity. Others still will sacrifice high level constucts for raw
> pedal to the metal speed, while others wouldn't dream of this sacrifice.[/color]

And people who have freely chosen Python appear to share enough core
values (simplicity, one obvious way to do it, etc) to be very far from any
splintering yet. Why does that surprise you?
[color=blue]
> What I'm getting at is that I can understand why people don't like
> Macros. As David Mertz said, some people are just wired in dramatically
> different ways.[/color]

Well, it's nice that you understand this. I just wish more people on your
side did -- most seem to think I'm crazy, my posts boggle the mind, etc.

[color=blue]
> What get's me is when people (and I do this sometimes as well) expess an
> opinion as fact, and that all rational people will agree with them. So,
> for what it' worth, for the times I have expressed my opinion as the one
> true way of thinking, I'm sorry.[/color]

I don't think there's anything worth apologizing for, in believing the
opinion you hold is the true one. Insulting people who hold a different
rational opinion is of course another issue.

[color=blue]
> top secret pet project ;) ) every day. I very much respect your
> knowledge Alex, because I do believe you have some good insights, and I
> do enjoy discussing issues that we disagree on (when we aren't being
> "bristly" ;) ) because you have many times helped me to understand my
> own point of view better. So even though we don't always agree, I still
> appreciate your opinions.[/color]

Likewise -- for you and the other reasonable people on your side (right
now Pascal Costanza is the only one who comes to mind, but, as I said,
it's easy to start confusing people after a thread as long and confused
as this one).


I don't think macros are evil, either -- I just don't want them in
Python:-). Let me give an example: one thing my main client is working on
is a specialized language that represents information-models (actions in
them are in embedded Python), presentation-data to guide generic clients
for GUI / web / print presentation, etc. I do think we need macros there
sooner or later (and sooner would be better;-) -- simply to help remove
redundancy and duplication, because in this purely declarative language
there are no "functions" . (Were it not for language/metalanguage confusion
risks, and the issues of ensuring the clarity of error-diagnostics, python
functions emitting code in the specialized language [which gets compiled
into Python], i.e. "functions that run at compile-time", would be the
obvious solution, and we could hack them in within an afternoon -- but we
DO want to provide very clear and precise error diagnostics, of course,
and the language/metalanguage issue is currently open). You will note
that this use of macros involves none of the issues I have expressed about
them (except for the difficulty of providing good error-diagnostics, but
that's of course solvable).


Alex

[dewatf]

Re: Python syntax in Lisp and Scheme

On Wed, 08 Oct 2003 18:28:36 +1300, "Greg Ewing (using news.cis.dfn.de )"
<g2h5dqi002@sne akemail.com> wrote:
[color=blue]
>Hans Nowak wrote:
>[color=green]
>> Hmm, if I recall correctly, in Latin the plural of 'virus' is 'virus'.[/color]
>
>Actually, the last discussion of this that I saw (can't remember where)
>came to the conclusion that the word 'virus' didn't *have* a plural
>in Latin at all, because its original meaning didn't refer to something
>countable.[/color]

'virus' (slime, poison, venom) is a 2nd declension neuter noun and
technically does have a plural 'viri'. However such nouns were usually
only used in the nominative and accusative singular in latin. You don't
normally want to start a sentence with 'venoms'. As you said 'virus'
didn't refer to something you usually count, and also in latin 'viri' is
the nominative for 'men' which you do want to use a lot.

The latin plural of census is census (with a long u, 4th declension).

So in English use viruses.

dewatf.

[Daniel P. M. Silva]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:[color=blue]
> As for me personally, and for my typical customers, we have lower
> appetite for risk:[/color]

Right, and your customers use no C apps.
[color=blue]
> In other words, I'm an engineer, not a scientist. Scientists whose
> goals are not the programs they write -- all those for whom the
> programs are mere tools, not goals in themselves -- tend to feel
> likewise about programming and other technologies that support
> their main work but are secondary to it, though they may have
> ambitions as burning as you wish in other, quite different areas.
>
> So, maybe, your favourite technologies are best for research in
> computer science itself, or to develop "artificial intelligence" programs
> (has the term gone out of fashion these days?) and other programs
> pushing the envelope of computer science and technology -- and
> mine are best for the purpose of delivering normal, useful, working
> applications safely and reliably. If this is true, there is surely space
> for both in this world.[/color]

How depressing. Leave the powerful languages to those with Computer Science
degrees and let the "software engineers" use weaker systems? What happens
when more functionality is needed (eg., web services)?

It's now nearly the end of 2003 and web applications are still created with
old, flawed technologies -- CGI, server pages, and explicit session
objects. Wouldn't it be nice if web applications were written like, well,
applications?

# my web adder
print_result( get_number() + get_number() )

where print_result sends out a web page, and get_number gets a number from a
web request.
[color=blue]
>[color=green]
>> things. If you have no ambitions beyond writing
>> yet-another-standard-web-app then macros are not for you. But if your[/color][/color]

He's wrong. "Advanced" technologies like continuations and macros are
exactly what are needed to make web apps work correctly. The web-app
writer doesn't have to know he's using any of it, but even the Apache
people realized they needed to provide more power in their application
framework.
[color=blue]
> [...] I basically
> feel there's a huge unfilled demand for perfectly normal applications,
> best filled by technologies such as Python, which, I find, maximize the
> productivity of professional programmers in developing such apps and
> frameworks for such apps, AND empower non-professional programmers
> to perform some of their own programming, customizing, and the like.
> [...]
> So, general macros in a general-purpose language are not for me, nor for
> all those who feel like me -- not for _production_ use, at least, though I
> do see how they're fun to play with.[/color]

What the non-professional programmer wants to write a program using two or
more languages? Should we restrict him? Or give him the tools...
[color=blue]
> (py-eval "x = 1")
> (define py_x (in-python (ns-get 'x)))
> (define scm_x (->scheme py_x))
> scm_x[/color]
1[color=blue]
> (in-python (ns-set! 'x (->python (+ 2 scm_x))))
> (py-eval "print x")[/color]
3

In this case, a special form is again needed:

(define-syntax (in-python stx)
(syntax-case stx ()
[(_ expr) #`(parameterize ([current-namespace pns])
expr)]))

- DS

[Daniel P. M. Silva]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:[color=blue][color=green]
>> Furthermore, it has been suggested more than once that a valid
>> working model is that a good Lisp programmer can provide a
>> domain-specific language for the non-professional programmer. It's very
>> likely that a DSL matches better the needs of the user than some
>> restricted general-purpose language.[/color]
>
> Another *shrug* And a good C programmer can provide a
> domain-specific language for the non-professional programmer.
>[/color]

The last thing we need in this world is more non-professional programmers
writing C programs to make software even more unstable. The ATM near where
I work crashes enough as it is.

You can restrict a DSL in lisp/scheme to the point of not allowing it to
call eval, for example. Can you restrict a C programmer's ability to
dereference NULL? Can you hide 'exec' from the Python newbie?
[color=blue]
> Any good Python programmer could make an implementation
> of a Lisp (slow, and not all of GC Lisp, but a Lisp) in Python, like
>
> import lisp
> def spam(distance):
> """(time_to_fal l 9.8 distance)"""
> spam = lisp.convert(sp am)
>
> def time_to_fall(g, distance):
> print "The spam takes", (2.0*distance/g)**(0.5), "seconds to fall"
>
> print spam(10)
>[/color]

Please let me know if you hear of anyone implementing lisp/scheme in
Python :)
[color=blue][color=green]
>> If it's only a syntactical issue, then it's a safe bet that you can add
>> that to the language. Syntax is boring.[/color]
>
> Umm... Sure. C++ can be expressed as a parse tree, and that
> parse tree converted to an s-exp, which can be claimed to be
> a Lisp; perhaps with the right set of macros.
>
> Still doesn't answer my question on how nicely Lisp handles
> the 'unexpected' need of allocating objects from different
> memory arenas.[/color]

Just like Python does: native modules.

- DS

[Hans Nowak]

Re: Python syntax in Lisp and Scheme

dewatf wrote:[color=blue]
> On Wed, 08 Oct 2003 18:28:36 +1300, "Greg Ewing (using news.cis.dfn.de )"
> <g2h5dqi002@sne akemail.com> wrote:
>
>[color=green]
>>Hans Nowak wrote:
>>
>>[color=darkred]
>>>Hmm, if I recall correctly, in Latin the plural of 'virus' is 'virus'.[/color]
>>
>>Actually, the last discussion of this that I saw (can't remember where)
>>came to the conclusion that the word 'virus' didn't *have* a plural
>>in Latin at all, because its original meaning didn't refer to something
>>countable.[/color]
>
>
> 'virus' (slime, poison, venom) is a 2nd declension neuter noun and
> technically does have a plural 'viri'.[/color]

Doesn't it belong to the group that includes 'fructus'? Of course this has
nothing to do with the plural used in English, but still... :-)

This page, which has a lot of info on this issue, seems to think so:

http://www.perl.com/language/misc/virus.html

--
Hans (hans@zephyrfal con.org)

http://zephyrfalcon.org/