Python syntax in Lisp and Scheme

[Pascal Costanza]

Andrew Dalke wrote:

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

I don't understand that last sentence. Could you clarify this a bit? You 
don't want to say that there is an inherent dichotomy between text and 
speed, do you?!?

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

...but you probably know from the start where to find the menus, what 
the shortcuts are for opening and saving files, how to find the online 
help, and so forth.

Lisp also has this to a certain degree: It's always clear what 
constitutes the meaning of an s-expression, namely its car, no matter 
what language "paradigm" you are currently using.

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

No, not really. :)

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

I know people who have even started to use s-expression for mathematical 
notation (on paper), because they find it more convenient.

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

There is some research going on to extend Lisp even in this regard 
(incorporating more ways of expression).

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

Well, maybe I am wrong. However, in a recent example, a unit test 
expressed in Python apparently needed to say something like 
"self.assertEqual ...". Who is this "self", and what does it have to do 
with testing? ;)

>>>>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 additional syntax makes specific things easier, then in god's name 
just add it! The loop macro in Common Lisp is an example of how you can 
add syntax to make certain things easier. This is not rocket science.

The point here is that for most languages, if you want to add some 
syntax, you have to change the definition of the language, extend the 
grammar, write a parser, extended a compiler and/or interpreter, maybe 
even the internal bytecode representation, have wars with other users of 
the language whether it's a good idea to change the language that way, 
and so forth. In Lisp, you just write a bunch of macros and you're done. 
No problems with syntax except if you want them, most of the time no 
problems with changes to the language (far less than in other 
languages), no messing around with grammars and related tools, no need 
to know about compiler/interpreter internals and internal 
representation, no wars with other language users, and so forth.

Syntax is boring. ;)

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

OK, I am sorry that I have lost focus here. You have given this example 
as one that shows what probably cannot not be done in Lisp out of the 
box. However, most Lisp implementations provide a way to access native 
code and in that way deal with specific features of the operating 
system. And there is a de-facto standard for so-called foreign function 
calls called UFFI that you can use if you are interested in a 
considerable degree of portability.

I don't know a lot about the specifics of shared memory, so I can't 
comment on your specific questions.

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

This should be possible as a combination of a FFI/UFFI and the CLOS MOP. 
AFAIK, you can define the memory layout and the allocation of memory for 
specific metaclasses. However, I really don't know the details.

The paper at 
http://www-db.stanford.edu/~paepcke/shared-documents/mopintro.ps might 
be interesting. For UFFI, see http://uffi.b9.com/

As Paul Graham put it, yes, there is some advantage when you use the 
language the operating system is developed in, or it ++.

Pascal