Python syntax in Lisp and Scheme

[Alex Martelli]

Andrew Dalke wrote:

> Pascal Costanza:
>> [quantum programming]
> 
> While an interesting topic, it's something I'm not going to worry about.

Me neither, for now.

> And if I did, it would be in Python ;)

I suspect no existing language would be anywhere near adequate.
But if any current programming concept could stretch there, it might
be that of "unrealized until looked-into set of things", as in, Haskell's
"lazy" (nonstrict) lists.  Now lists are sequential and thus quantumly
inappropriate, but perhaps it's a start.

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

I suspect we may have to map the 'ensembles' down to sets of
items, just as we generally map concurrency down to sets of
sequential actions, in order to be able to reason about them (though
I have no proof of that conjecture).  IF you have to map more
complicated intrinsics down to sequential, deterministic, univocal
"things", I'm sure you could do worse than Lisp.  As to whether
that makes more sense than dreaming up completely different
languages having (e.g.) nondeterminism or multivocity as more
intrinsic concepts, I pass: it depends mostly on what human beings
will find they need to use in order to reason most effectively in
this new realm -- and quite likely different humans will find they
have different needs in this matter.


> 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

Yeah, well, I fear the answer will be yes (it could), but it won't
do so since you haven't _asked_ it to wake you up, only if it
could.  ME, I definitely don't want to use natural language with
all of its ambiguity for anything exept communicating with
other human beings, thankyouverymuch.

> a language designed for text, not speed.

*blink* what does THAT doubtful assertion have to do with anything
else we were discussing just now...?  I think lisp was designed for
lists (as opposed to, say, snobol, which WAS "designed for text") and
that they're a general enough data structure (and supplemented in
today's lisps with other good data structures) that they'll be quite good
for all kinds of 'normal' (deterministic &c) programming.  As for speed,
I'm sure it's easier to get it out of lisp than out of python right now.
So what's your point, and its relation to the above...?


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

Yes, I agree this IS generally accepted (with, of course, some dissenters,
but in a minority).

> My spreadsheet program looks different from my word processor

Sure, so do mine, but their menus are quite similar -- in as much as
it makes sense for them to have similar operations -- and ditto ditto
for their toolbars, keyboard shortcuts, etc etc.  I.e. the differences
only come "when needed for a specific domain" just as Pascal just
said.  So I don't know what you're intending with this answer.

> is more in common.  Still, the phrase "practicality beats purity" is
> seems appropriate here.

Uniformity is more practical than diversity: e.g. ctrl-c as the Copy 
operation everywhere means my fingers, even more than my brain, get
used to it.  If you assign ctrl-c to some totally different operation in
your gui app "because you think it's more practical" you're gonna
drive me crazy, assuming I have to use your app.  (That already
happens to me with the -- gnome based i think -- programs using
ctrl-z for minimize instead of undo -- I'm starting to have frayed
nerves about that even for GVIM, one of the programs I use most
often...:-).

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

Given the difficulty I'm having understanding your stance[s] in
this post, I do.  My own answer would be that syntax sugar is
in people's head anyway because of different contexts -- infix
arithmetic taught since primary school, indentation in outlines
and pseudocode, etc etc -- so, following that already-ingrained
set of conventions takes no "room to spare in people's heads" --
indeed, the contrary -- it saves them effort.  If people's head
started as "tabula rasa" it might be different, but they don't, so
that's a moot issue.

That much being said, I _do_ like prefix syntax.  In some cases
I need to sum a+b+c+d and repeating that silly plus rather than
writing (+ a b c d) grates.  Or I need to check a<b<c<d and
again I wish I could more summarily write (< a b c d).  When I
designed my own language for bridge-hands evaluation, BBL, I 
used prefix notation, though in the form operator ( operands )
[which I thought would have been easier for other bridge players 
to use], e.g.:

& (                      # weak NT opener requires AND of two things:
    s ( 1 g 4  3  3  3   # shape 4333 (any), or
        2 g 4  4  3  2   #       4432 (any), or
        3   3- 3- 3- 5   #       5332 with 5 clubs, or
        4   3- 3- 5  3-  #       5332 with 5 diamonds
      )
    < ( 12                    # as well as, 13-15 range for
        \+ SHDC c( 4 3 2 1 0) # normal Milton-Work pointcount
        16
      )
  )

Maybe readers are starting to understand why I don't WANT to
use a language I design myself;-).  Anyway, the language was
NOT enthusiastically taken up, until I wrote code generators with
a GUI accepting conditions in more "ordinary looking" notations
and building this, ahem, intrinsically "better" one;-) -- then, but only 
then, did other players start using this to customize hand generators
and the like.  (Yes, I did have macros, but puny enough that they
still required operator(operands) syntax -- they basically served only
to reduce duplication, or provide some little abstraction, not to
drastically change the language syntax at all).  Ah well -- maybe I
should just put the BBL (Turbo Pascal) implementation and (Italian-
language) reference manual online -- it still moves nostalgia in me!-)


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

My APL experience tells me this is false: conveniently expressing
solutions is HALF the problem -- you (and others!) have to be
able to read them back and maintain and alter them later too.

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

So jot your equations on a tablet-screen and look for a good
enriched text recognition system.  What's programming gotta
do with it?

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

Python even more so on the output side -- try getting a screen-reader to 
do a halfway decent job with it.  But what does this matter here?


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

You may want to teach by showing and having the computer
infer more general rules from example.  Whether the inference
engine will be best built in lisp, prolog, ocaml, mozart, whatever,
I dunno.  I don't think it will be optimally done in Python, though.
"Horses for courses" is my philosophy in programming.


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

Given the "everything is an object" (classes included) and every object
belongs to a class, you could indeed say that -- in much the same sense
as you may be said to always be aware that you're breathing air in
everyday life.  Such awareness is typically very subconscious, of course.

>> Why should one care? Why does the language force me to see that when it
>> really doesn't contribute to the solution?

I'm not sure in what sense "python forces you to see" that, e.g.,
the number 2 is an object -- or how can that fail to "contribute to
the solution".  Care to exemplify?

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

Yes to all of the above, in Python.  I don't get your point.

>>>> print sum(range(100))
> 4950
> 
> Where in that example are you aware that you are dealing with classes
> and objects?

Me?  At every step -- I know 'sum' names a builtin object that is a
function (belonging to the class of builtin functions) taking one argument
which is a sequence, 'range' names another builtin object returning
a list object, etc.  I'm not directly dealing with any of their classes --
I know they belong to classes, like any object does, but I have no need
to think about them in this specific statement (in fact, I hardly ever do;
signature-based polymorphism is what I usually care about, not class
membership, far more often than not).

But I don't get your points -- neither Andrew's nor Pascal's.  How does
this differ from the awareness I might have in some macro-enhanced
lisp where I would type (print (sum (range 100))) or the like?

> conjecture is that additional syntax can make some things easier.
> That a problem can be solved without new syntax does not
> contradict my conjecture.

But even if we provisionally concede your conjecture we are still
left wondering: is the degree of easing so high that it overcomes
the inevitable increase in complication, needed for a language to
have N+1 syntax forms where previously it only had N?  I.e., it's
in general a difficult engineering tradeoff, like many in language
design -- which is why I'd rather delegate the decisions on these
tradeoffs to individuals, groups and processes with a proven track
record for making a lot of them with complexive results that I find
delightful, rather than disperse them to myself & many others
(creating lots of not-quite-congruent language dialects).


Alex