Python syntax in Lisp and Scheme

[prunesquallor at comcast.net]

"Andrew Dalke" <adalke at mindspring.com> writes:

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

Oops, try again.  

  http://hampshire.edu/lspector/qgame.html
  http://www.het.brown.edu/people/andre/qlambda/
  http://mitpress.mit.edu/sicp/full-text/sicp/book/node88.html


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

Oops, try again.

  http://www.hpl.hp.com/techreports/94/HPL-94-30.html
  http://dynamo.ecn.purdue.edu/~qobi/software.html
  http://citeseer.nj.nec.com/siskind93screamer.html

If you were to select a language that has been used for *more* different
kinds of programming paradigms, you'd be hard pressed to find something
better than lisp.

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

Oops, it turns out that Lisp is used for handwriting recognition
in the banking industry.  I've heard rumors of Lisp being used
for voice recognition.

> Or, will there ever be a computer/robot combination I can
> teach to dance?  Will I do so in Lisp?

You want to teach a robot to dance?  I would prefer a cute woman,
myself.  Suit yourself, but you can use Lisp:

    http://citeseer.nj.nec.com/lee95programming.html


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

  http://www.double.co.nz/creatures/developer/sharedmemory.htm

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

Actually, it is obvious with a little thought.  Objects sharable
between X and Y must reside in the XY address space.  Objects
sharable between X and Z must reside in the XZ address space.

Since neither Y nor Z share their entire address space with X, there
exist outgoing edges in the heap of Y that do not refer to objects
within Y.  Presumably the author of the system thought of that.
(If not, he's in trouble before Z even exists.)  An object common
with X and Z is as opaque to Y as any other object in X. 

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

Why do you think this?  The api would be straighforward.  a
shared persistent memory would at least have these calls:

  allocate, which takes an allocation amount and returns
   some name for the object allocated,

  retrieve, which takes some name for an object and recovers
   the object itself (for use upon restarting)

  dereference, which takes an object and a field and returns
   or assigns the field.

An obvious way to integrate this into lisp is to make a
displaced array.