Python syntax in Lisp and Scheme

[Hans Nowak]

Re: Python syntax in Lisp and Scheme

Daniel P. M. Silva wrote:
[color=blue]
> Please let me know if you hear of anyone implementing lisp/scheme in
> Python :)[/color]

Well, there's Psyche:

http://www.xs4all.nl/~yduppen/site/psyche.html

--
Hans (hans@zephyrfal con.org)

http://zephyrfalcon.org/

[Daniel Silva]

Re: Python syntax in Lisp and Scheme

On Sat, 11 Oct 2003, Hans Nowak wrote:[color=blue]
> Daniel P. M. Silva wrote:
>[color=green]
> > Please let me know if you hear of anyone implementing lisp/scheme in
> > Python :)[/color]
>
> Well, there's Psyche:
>
> http://www.xs4all.nl/~yduppen/site/psyche.html[/color]

Excellent; thanks!

- DS

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Alex Martelli wrote:[color=blue]
> Kenny Tilton wrote:
> ...
>[color=green][color=darkred]
>>>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?[/color]

No, and Google is not as great as we think it is. :( I did after
extraordinary effort (on this my second try) find the original, but that
was just an application of the macro, not its innards, and I did not get
enough from his description to make out what it was all about. Worse, I
could not find your follow-up objections. I had stopped following this
thread to get some work done (and because I think the horse is dead).

All I know is that you are trying to round up a lynch mob to string up
WITH-MAINTAINED-CONDITION, and thet Lisp the language is doomed to
eternal damnation if we on c.l.l. do not denounce it. :)

No, seriously, what is your problem? That the macro would wlak the code
of the condition to generate a demon that would not only test the
condition but also do things to maintain the condition, based on its
parsing of the code for the condition?

You got a problem with that? Anyway, this is good, I was going to say
this chit chat would be better if we had some actual macros to fight over.

[Apologies up front: I am guessing left and right at both the macro and
your objections. And ILC2003 starts tomorrow, so I may not get back to
you all for a while.]

kenny

ps. Don't forget to read Paul Grahams Chapter's 1 & 8 in On Lisp, from
now on I think it is pointless not to be debating what he said, vs what
we are saying. The whole book is almost dedicated to macros. From the
preface:

"The title [On Lisp] is intended to stress the importance of bottom-up
programming in Lisp. Instead of just writing your program in Lisp, you
can write your own language on Lisp, and write your program in that.

"It is possible to write programs bottom-up in any language, but Lisp is
the most natural vehicle for this style of programming. In Lisp,
bottom-up design is not a special technique reserved for unusually large
or difficult programs. Any substantial program will be written partly in
this style. Lisp was meant from the start to be an extensible language.
The language itself is mostly a collection of Lisp functions, no
different from the ones you define yourself. What’s more, Lisp functions
can be expressed as lists, which are Lisp data structures. This means
you can write Lisp functions which generate Lisp code.

"A good Lisp programmer must know how to take advantage of this
possibility. The usual way to do so is by defining a kind of operator
called a macro. Mastering macros is one of the most important steps in
moving from writing correct Lisp programs to writing beautiful ones.
Introductory Lisp books have room for no more than a quick overview of
macros: an explanation of what macros are,together with a few examples
which hint at the strange and wonderful things you can do with them.

"Those strange and wonderful things will receive special attention here.
One of the aims of this book is to collect in one place all that people
have till now had to learn from experience about macros."

Alex, have you read On Lisp?


--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Andrew Dalke wrote:[color=blue]
> Guess you don't know Knuth.[/color]

Eight years to do TeX? How smart can he be? He should have used Lisp.
[color=blue]
> The smartest people I know aren't programmers. What does
> that say?[/color]

Aren't you the scientist who praised a study because statistics showed
the studies statistics had a better than even chance of not being
completely random? Credibility zero, dude. (if you now complain that it
was fully a 75% chance of not being completely random, you lose.)


--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Daniel Silva]

Re: Python syntax in Lisp and Scheme

On Sat, 11 Oct 2003, Hans Nowak wrote:[color=blue]
> Daniel P. M. Silva wrote:
>[color=green]
> > Please let me know if you hear of anyone implementing lisp/scheme in
> > Python :)[/color]
>
> Well, there's Psyche:
>
> http://www.xs4all.nl/~yduppen/site/psyche.html[/color]

Excellent; thanks!

- DS

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Peter Seibel:[color=blue]
>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)))[/color]

Python bases its unit tests on introspection. Including the
full scaffolding, the equivalent for Python would be

import unittest
import foo_module # I'm assuming 'foo' is in some other module

class FooTestCase(uni ttest.TestCase) :
def testFoo(self):
self.assertEqua ls(foo_module.f oo(1, 2, 3), 42)
self.assertEqua ls(foo_module.f oo(4, 5, 6), 99)

if __name__ == '__main__':
unittest.main()

Here's what it looks like
[color=blue][color=green][color=darkred]
>>> class FooTestCase(uni ttest.TestCase) :[/color][/color][/color]
.... def testFoo(self):
.... self.assertEqua ls(foo(1,2,3), 42)
.... self.assertEqua ls(foo(4,5,6), 99)
....[color=blue][color=green][color=darkred]
>>> unittest.main()[/color][/color][/color]
F
=============== =============== =============== =============== ==========
FAIL: testFoo (__main__.FooTe stCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "<interacti ve input>", line 4, in testFoo
File "E:\Python23\Li b\unittest.py", line 302, in failUnlessEqual
raise self.failureExc eption, \
AssertionError: 42 != 99

A different style of test can be done with doctest, which uses Python's
docstrings. I'll define the function and include an invalid example
in the documentation.

def foo(x, y, z):
"""Returns 42
[color=blue][color=green][color=darkred]
>>> foo(1,2,3)[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> foo(4,5,6)[/color][/color][/color]
99[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]
""""
return 42

Here's what I see when I run it.
[color=blue][color=green][color=darkred]
>>> import doctest
>>> doctest.testmod ()[/color][/color][/color]
*************** *************** *************** *************** *****
Failure in example: foo(5,6,7)
from line #3 of __main__.foo
Expected: 99
Got: 42
*************** *************** *************** *************** *****

Doctests are fun. ;)
[color=blue]
> 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.[/color]

The unittest example I have makes them all part of the same test case.
To be a different test case it needs a name. If it has a name, it can
be tested independent of the other tests, eg, if you want to tell the
regression framework to run only one of the tests, as when debugging.
If you have that functionality you'll have to specify the test by number.
[color=blue]
> 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.)[/color]

The Python code is more verbose in that regard because ==
isn't a way to write a function. I assume you also have tests for
things like "should throw exception of type X" and "should not
throw expection" and "floating point within epsilon of expected value"?
[color=blue]
> Test Failure:
>
> Test Name: (FOO-TESTS)
> Test Case: (= (FOO 1 2 3) 42)
> Values: (FOO 1 2 3): 6[/color]

Feel free to compare with the above. The main difference, as you
point out below, is that you get to see the full expression. Python
keeps track of the source line number, which you can see in the
traceback. If the text was in a file it would also show the contents
of that line in the traceback, which would provide equivalent output
to what you have. In this case the input was from a string and it
doesn't keep strings around for use in tracebacks.

(And the 'doctest' output includes the part of the text used to
generate the test; the previous paragraph only applies to unittest.)

I expect a decent IDE would make it easy to get to an
error line given the unittest output. I really should try one of
the Python IDEs, or even just experiment with python-mode.

I expect the usefulness of showing the full expression to be
smaller when the expression is large, because it could be
an intermediate in the expression which has the problem, and
you don't display those intermediates.
[color=blue]
> 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:[/color]

Python's introspection approach works by looking for classes of a
given type (yes, classes, not instances), then looking for methods
in that class which have a given prefix. These methods become the
test cases. I imagine Lisp could work the same way, except that
because other solutions exist (like macros), there's a prefered
reason to choose another style.

The Python code is the same number of lines as your code, except
that it is more verbose. It does include the ability for tests to have
a setup and teardown stage, which appears to be harder for your
code to handle.
[color=blue]
> 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:[/color]
[color=blue]
> 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.[/color]

You are correct in that Python's way of handling the output doesn't
include the expression which failed. Intead, it includes the location
(source + line number) in the stack trace and if that source is a file
which still exists it shows that line which failed.

A solution which would get what you want without macros is
the addition of more parse tree information, like the start/end positions
of each expression. In that way the function could look up the
stack, find the context from which it was called, then get the full
text of the call. This gets at the code "from the other direction",
that is, from looking at the code after it was parsed rather than
before.

Or as I said, let the IDE help you find the error location and
full context.
[color=blue]
> 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?[/color]

I'll let you decide if Lisp's introspection abilities provide an alternate
non-macro way to handle building test cases which is just as short.

Knowing roughly no Lisp and doing just pattern matching, here's
a related solution, which doesn't use classes.

(defun utest-foo ()
(= (foo 1 2 3) 42)
(= (foo 4 5 6) 99))

...
(run-unit-tests)

where run-unit-tests looks at all the defined symbols, finds
those which start with 'utest-', wraps the body of each one
inside a 'check' then runs the
(eval-when (:compile-toplevel :load-toplevel :execute)
..
on the body.

If that works, it appears to make the unit test code slightly
easier because the 'check' macro is no longer needed in each
of the test cases; it's been moved to 'run-unit-tests' and can
therefore work as a standard function.

Andrew
dalke@dalkescie ntific.com

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:
[color=blue]
> Me:
>[color=green][color=darkred]
>>>My continued response is that [Lisp is] not optimal for all
>>>domains.[/color][/color]
>
>
> Pascal Costanza:
>[color=green]
>>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.[/color]

Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
[color=blue]
> Pascal Costanza:
>[color=green]
>>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.[/color]

Right.
[color=blue]
> 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]

....and you expect me to have fully explored it? If this topic is so
interesting to you, why don't you just grab a Common Lisp environment
and start working on it? ;)

I am pretty sure you can get very far.
[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]

Sure, but it's much more work.
[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]

Sure, but inconvenient.
[color=blue][color=green]
>>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.[/color]

Sure, there is no way around that. But you can reduce the tediousness in
the long run.

I believe it is an accepted fact that uniformity in GUI design is a good
thing because users don't need to learn arbitrarily different ways of
using different programs. You only need different ways of interaction
when a program actually requires it for its specific domain.

That's pretty much the same when you program in Lisp. It takes some time
to get used to s-expressions, but afterwards you forget about syntax and
focus on the real problems.
[color=blue]
> 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]

Sure, but is it worth it?
[color=blue][color=green]
>>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]

Probably not. This question is too general though for my taste.
[color=blue][color=green][color=darkred]
>>>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]

Convenience is what matters. If you are able to conveniently express
solutions for hard problems, then you win. In the long run, it doesn't
matter much how things behave in the background, only at first.

Or do you really still care about how sorting algorithms work? No, you
look for an API that has some useful sorting functions, and then you
just use them.

Macros are just another tool to create new abstractions that allow you
to conveniently express solutions for hard problems.

It seems to me that in Python, just as in most other languages, you
always have to be aware that you are dealing with classes and objects.
Why should one care? Why does the language force me to see that when it
really doesn't contribute to the solution?

That's why lambda expressions are sometimes also not quite right. When I
want to execute some code in some context, why should I care about it
being wrapped in a lambda expression to make it work? How does that
contribute to the problem I am trying to tackle?

I want to think in terms of the problem I need to solve. Lisp is one of
the very rare languages that doesn't force me to think in terms of its
native language constructs.
[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.[/color]

That's computational equivalence, and that's not interesting.
[color=blue]
> Still doesn't answer my question on how nicely Lisp handles
> the 'unexpected' need of allocating objects from different
> memory arenas.[/color]

If it's a good Lisp library I would expect it to work like this:

(with-allocation-from :shared-memory
...)

;)

Any more questions?
[color=blue][color=green]
>>Sounds like a possible application for the CLOS MOP.[/color]
>
>
> Or any other language's MOP.[/color]

Sure.
[color=blue][color=green]
>>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. ;)[/color]

Thanks for your kind words. ;)


Pascal

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Kenny Tilton:[color=blue]
> Aren't you the scientist who praised a study because statistics showed
> the studies statistics had a better than even chance of not being
> completely random? Credibility zero, dude. (if you now complain that it
> was fully a 75% chance of not being completely random, you lose.)[/color]

Wow! You continue to be wrong in your summaries:

- I am not a scientist and haven't claimed to be one in about 8 years

- I didn't 'praise' the study, I pointed out that it exists and that it
offers
some interesting points to consider. At the very least it makes a
testable prediction.

- After someone asserted that that study had been "debunked" I asked for
more information on the debunking, and pointed out the results of
one experiment suggest that the language mapping was not complete
bunkum. (Note that since 100% correlation is also a 'better than even
chance' your statement above is meaningless. What is your
threshold?)

I would be *delighted* to see more studies on this topic,
even ones which state that COBOL is easier to use than Python.

- When I make statements of belief, I present where possible the
sources and the analyses used to justify the belief and, in an
attempt at rigour, the weaknesses of those arguments. As such,
I find it dubious that my credibility can be lower than someone
making claims based solely on gut feelings and illogical thought.
I take that back; a -1.0 credibility makes a wonderful oracle.

Given how imprecise you are in your use of language (where your
thoughtless turns of phrase gracelessly demean those who don't believe
that programming is the be-all and end-all of ambitions), your inability
to summarize matters correctly, and your insistance on ad hominum attacks
(dude!) over logical counter-argument and rational discourse, I'm surprised
you can make a living as a programmer or in any other field which
requires mental aptitude and the ability to communicate.

Andrew
dalke@dalkescie ntific.com

[Steve Williams]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:
[snip][color=blue]
> 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).[/color]

finally, a breath of fresh air.

[Coby Beck]

Re: Python syntax in Lisp and Scheme


"Andrew Dalke" <adalke@mindspr ing.com> wrote in message
news:rr0ib.7732 $dn6.1011@newsr ead4.news.pas.e arthlink.net...[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]

Now you're obviously just trying to be difficult! Reminds me of a thread a
while back where someone argued that C could so dynamically compile code and
posted an example that wrote a hello-world in a string, wrote it to a file,
called gcc on it and then system-called the .so file!

Or is there something else you mean besides design the language, implement a
parser, write a compiler? Yes you can do that in C.
[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]

I don't get your point at all. At least not how it possibly applies to a
discussion of using macros to create domain specific languages.
[color=blue][color=green]
> > 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.[/color]

This is just the same memorizing that applies to application specific
functions, classes etc. Not at all like memorizing @ % $ ; { } & etc.
Really, this argument is based on pure FUD. It is not the norm to use
macros to do anything at all obfuscating. One of the most controversial
macros has got to be loop, and it is ridiculed for something close to what
you seem to be arguing: it creates a very different and unlisp-like
sublanguage.

But even that, it is not:
(loop ^x %% foo==bar -> baz)

it is:
(loop for x from foo upto bar finally return baz)

Not hard to memorize what FROM and UPTO mean.
[color=blue]
> 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]

My head prefers to be full of more important things, that's all.
[color=blue][color=green][color=darkred]
>>>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][/color][/color]
[color=blue][color=green][color=darkred]
>>> Ahh, but that assumes that behaviour is the only important thing
>>> in a language.[/color][/color][/color]
[color=blue][color=green]
>> 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]

Just have another look. He did not even say behaviour is the most
important, let alone the only important thing.

But in the global trade of language design (because remember, everything is
a trade-off) behaviour *is* more important than syntax *if* your goals are
primarily technical rather than social.

Nothing wrong with social goals, but you should not be naive when it comes
to considering what you have traded in for personal notions of ease of
learning.
[color=blue]
> Still doesn't answer my question on how nicely Lisp handles
> the 'unexpected' need of allocating objects from different
> memory arenas.[/color]

I don't think this is a reasonable discussion point. You are presumably
trying to show us an example of a problem lisp is not flexible enough to
handle, but you have not presented a problem to solve, you have presented a
solution to implement. These are entirely different things.

--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")

[Coby Beck]

Re: Python syntax in Lisp and Scheme


"Andrew Dalke" <adalke@mindspr ing.com> wrote in message
news:we0ib.7725 $dn6.7509@newsr ead4.news.pas.e arthlink.net...[color=blue]
> The smartest people I know aren't programmers. What does
> that say?[/color]

Nothing surprising! ;)

--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")

[Terry Reedy]

Re: Python syntax in Lisp and Scheme


"Pascal Costanza" <costanza@web.d e> wrote in message
news:bm9it8$6j5 $1@newsreader2. netcologne.de.. .[color=blue]
> Does Python allow local function definitions?[/color]

Module level functions are local to the module unless imported by
another module. Nested functions are local to the function they are
nested within unless explicitly returned. Methods are local to
classes and subclasses. Lambda expressions are very local unless
somehow passed around.

I am not sure which best meets your intention.
[color=blue]
>Can they shadow predefined functions?[/color]

Yes, named objects, including functions can (locally) shadow
(override) builtins. It is considered a bad habit/practice unless
done intentionally with a functional reason.

Terry J. Reedy

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Pascal Costanza:[color=blue]
> [quantum programming][/color]

While an interesting topic, it's something I'm not going to worry about.
And if I did, it would be in Python ;)

I bring it up as a counter-example to the idea that all modes of
programming have been and can be explored in a current Lisp.
I conjectured one interesting possibility -- that of handling ensembles
of possible solutions to a given problem.

In retrospect I should have given a more obvious possibility.
As some point I hope to have computer systems I can program
by voice in English, as in "House? Could you wake me up
at 7?" That is definitely a type of programming, but Lisp is
a language designed for text, not speed.

Pascal Costanza:[color=blue]
> I believe it is an accepted fact that uniformity in GUI design is a good
> thing because users don't need to learn arbitrarily different ways of
> using different programs. You only need different ways of interaction
> when a program actually requires it for its specific domain.[/color]

My spreadsheet program looks different from my word processor
looks different from my chemical structure editor looks different from
my biosequence display program looks different from my image
editor looks different from my MP3 player looks different from my
email reader looks different from Return to Castle Wolfinstein ....

There are a few bits of commonality; they can all open files. But
not much more. Toss out the MP3 player and RtCW and there
is more in common. Still, the phrase "practicali ty beats purity" is
seems appropriate here.
[color=blue][color=green]
> > 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]
>
> Sure, but is it worth it?[/color]

Do you have any doubt to my answer? :)
[color=blue]
> Convenience is what matters. If you are able to conveniently express
> solutions for hard problems, then you win. In the long run, it doesn't
> matter much how things behave in the background, only at first.[/color]

Personally, I would love to write equations on a screen like I
would on paper, with integral signs, radicals, powers, etc. and
not have to change my notation to meet the limitations of computer
input systems.

For Lisp is a language tuned to keyboard input and not the full
range of human expression. (As with speech.)

(I know, there are people who can write equations in TeX as
fast as they can on paper. But I'm talking about lazy ol' me
who wants the covenience.)

Or, will there ever be a computer/robot combination I can
teach to dance? Will I do so in Lisp?
[color=blue]
> It seems to me that in Python, just as in most other languages, you
> always have to be aware that you are dealing with classes and objects.
> Why should one care? Why does the language force me to see that when it
> really doesn't contribute to the solution?[/color]

Hmmm.. Is the number '1' an object? Is a function an object?
What about a module? A list? A class?
[color=blue][color=green][color=darkred]
>>> print sum(range(100))[/color][/color][/color]
4950[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Where in that example are you aware that you are dealing with classes
and objects?
[color=blue][color=green][color=darkred]
> >>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.[/color]
>
> That's computational equivalence, and that's not interesting.[/color]

Which is why I didn't see the point of original statement. My
conjecture is that additional syntax can make some things easier.
That a problem can be solved without new syntax does not
contradict my conjecture.
[color=blue]
> If it's a good Lisp library I would expect it to work like this:
>
> (with-allocation-from :shared-memory
> ...)
>
> ;)
>
> Any more questions?[/color]

Yes. Got a URL for documentation on a Lisp providing access
to shared memory? My guess is that the Lisp runtime needs
to be told about the arenas and that the multiple instances of
Lisp sharing the arena must use some extra IPC to handle
the distributed gc.

It gets worse if program X forks copies Y and Z, with shared
memory XY between X and Y (but not Z) and XZ between
X and Z (but not Y). X needs to be very careful on which
data is copied, and it isn't immediately obvious what happens
when some object from XZ is inserted into a list accessible
to Y via XY.

Consider also a "persistent memory" server running in C
(or hardware access to some sort of non-volatile memory.)
You can use standard IPC to get an initially zeroed memory
block and are free to use that memory without restrictions.
It's persistent after program exit so when the program restarts
it can reconnect to shared memory and get the data as it
was at exit.

This service is straight-forward to support in C/C++. It
sounds like for Lisp you are dependent on the implementation,
in that if the implementation doesn't support access to its
memory allocator/gc subsystem then it's very hard to
write code for this hardware on your own. It may be
possible to use an extension (written in C? ;) to read/write
to that persistent memory using some sort of serialization,
but that's the best you can do -- you don't have live objects
running from nonvolatile store -- which is worse than C++.


Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Coby Beck:[color=blue]
> Now you're obviously just trying to be difficult![/color]

Hmm, I think you are correct. This discussion has worn me out
and I'm reacting now more out of crabbishness than thoughtfulness.

I hereby withdraw from this thread. Or at least from cross-posting
outside of c.l.py ;)

Andrew
dalke@dalkescie ntific.com

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Andrew Dalke wrote:
[color=blue]
> Given how imprecise you are in your use of language[/color]

Ah, but there was a 75% chance that my remarks were not /completely/
random, so my unfairness towards you can't be complete bunkum.

:)


--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey