Python syntax in Lisp and Scheme

[Andrew Dalke]

Pascal Costanza:
> [quantum programming]

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

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 "practicality beats purity" is
seems appropriate here.

> > 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.
>
> Sure, but is it worth it?

Do you have any doubt to my answer?  :)

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

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?

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

Hmmm..  Is the number '1' an object?  Is a function an object?
What about a module?  A list?  A class?

>>> print sum(range(100))
4950
>>>

Where in that example are you aware that you are dealing with classes
and objects?

> >>If it's only a syntactical issue, then it's a safe bet that you can add
> >>that to the language. Syntax is boring.
> >
> > 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.
>
> That's computational equivalence, and that's not interesting.

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.

> If it's a good Lisp library I would expect it to work like this:
>
> (with-allocation-from :shared-memory
>    ...)
>
> ;)
>
> Any more questions?

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 at dalkescientific.com