Python syntax in Lisp and Scheme

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Daniel Berlin wrote:
...[color=blue][color=green][color=darkred]
>>>> Libraries distributed as binaries are not portable across different
>>>> C++ implementations on the same machine (as a rule).
>>>
>>> This isn't true anymore (IE for newer compilers).[/color]
>>
>> Wow, that IS great news! Does it apply to 32-bit Intel-oid machines
>> (the most widespread architecture)[/color]
>
> Yes, but not windows.[/color]

Aw:-(. Oh well, so much for the hope of easy extensibility of Python
on Windows by non-MS compilers:-(.
[color=blue][color=green]
>> I'm not very familiar with Python on the Mac but I think it uses
>> another
>> commercial compiler (perhaps Metrowerks?), so I suspect the same
>> question may apply here.[/color]
>
> It depends. I've built it with both.[/color]

I'm sure you can build Python with different compilers, but I was wondering
about the widely distributed pre-built version, the one Apple includes as
part of OS/X.
[color=blue]
> At least on Mac, Apple's gcc -fast is better than any other compiler
> around, according to recent benchmarks.
>
> Unsurprising to me, but i'm a gcc hacker, so i might be biased a bit. :P
>
> Most, if not all, optimizations that commercial compilers implement are
> or are being implemented in gcc for 3.5/3.6.[/color]

Great news. But I doubt that Python on Windows can simply drop the
use of MSVC++, anyway:-(.


Alex

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Joe Marshall wrote:
...[color=blue][color=green]
>> Do I want a single writing tool, or separate pencils, pens, markers,
>> highlighters... ? Do I want a single notation to write down ANYthing
>> on paper, or separate ones for music, algebraic formulas, shopping[/color][/color]
...[color=blue]
> A single web browser?[/color]

I far prefer to have on my cellphone one that's specialized for its small
screen and puny cpu/memory, and on more powerful computers, more
powerful browsers. Don't you?
[color=blue]
> A single editor?[/color]

I prefer to have one for text files, a separate one for video files, and
so on. Editing text and editing video have SO little in common...
[color=blue]
> A single operating system?[/color]

On my cellphone all the way to the datacenter? MS may dream about
that (even though all the "windows" versions they try to sell may have
in common only the name or little more), but it's definitely not my
preference -- I think the OS's for cellphones and those for powerful
servers have too little in common to be "a single OS" sensibly.
[color=blue]
> A single character encoding scheme?[/color]

Now that would be nice, IF one could get away with it. Unfortunately,
throwing away all of the gigabytes of text recorded as other than UCS-4
is definitely impractical, so we're doomed to live with several.
[color=blue]
> A single analogy?[/color]

Perish the thought -- the more the merrier.


Alex

[prunesquallor@comcast.net]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleaxit@yahoo. com> writes:
[color=blue]
> Joe Marshall wrote:
> ...[color=green][color=darkred]
>>> Do I want a single writing tool, or separate pencils, pens, markers,
>>> highlighters... ? Do I want a single notation to write down ANYthing
>>> on paper, or separate ones for music, algebraic formulas, shopping[/color][/color]
> ...[color=green]
>> A single web browser?[/color]
>
> I far prefer to have on my cellphone one that's specialized for its small
> screen and puny cpu/memory, and on more powerful computers, more
> powerful browsers. Don't you?[/color]

Cellphone? Why on earth would I want one of those?
[color=blue][color=green]
>> A single operating system?[/color]
>
> On my cellphone all the way to the datacenter?[/color]

A cellphone with an OS?! The phone I use is implemented
with *wires*.

[Alexander Schmolck]

Re: Python syntax in Lisp and Scheme

[narrowing down to c.l.l and c.l.p]
prunesquallor@c omcast.net writes:
[color=blue][color=green]
> > Significantly, AFAICT you can easily do this unambiguously and *locally*,
> > for example your editor can trivially perform this operation on cutting a
> > piece of python code and its inverse on pasting (so that you only
> > cut-and-paste the 'local' indentation). Prima facie I don't see how you
> > loose any fine control.[/color]
>
> Only if your cut boundaries are at the same lexical level. If you cut
> across boundaries, it is no longer clear what should happen at the paste.[/color]

The only unclarity would arise from dedents of more than one level on the
corner of your cut region, I think.
[color=blue]
> Also, it is frequently the case that you need to `tweak' the code after
> you paste it.[/color]

Sure, but I don't generally feel that tweaking python code in emacs is
particularly inconvenient (it is not always as convenient as tweaking lisp
code, which is partly due to the fact that essentially there isn't any proper
implementation of the sexp commands for non-lisp modes; OTOH some operations
are more convenient).
[color=blue]
> You misunderstand me. In a python block, two expressions are
> associated with each other if they are the same distance from the left
> edge. This is isomorphic to having a nametag identifying the scope
> of the line. Lines are associated with each other iff they have the
> same nametag. Change one, and all must change.[/color]

Hardly a problem with a decent editor (and surely less of a problem even with
the proverbial notepad than getting the closing paren in the right spot and
reindenting everything).
[color=blue]
> because the grouping information is replicated on each line, I have to
> fix this information in the six different places it is encoded:[/color]

Why, for example, not just first insert the new if statement and then run an
editor command that indents all the following lines up to the same indent
level one further indent level? To me this wouldn't seem to me have
intrisically more room for screw-ups than inserting a '(WHEN' and an
additional ')'.
[color=blue]
> The fact that the information is replicated, and that there is nothing
> but programmer discipline keeping it consistent is a source of errors.[/color]

Sure there is. Your editor and immediate visual feedback (no need to remember
to reindent after making the semantic changes).
[color=blue][color=green]
> > I don't understand why this is any different to e.g. ')))))' in Lisp. The
> > closing ')' for DEFUN just looks the same as that for IF.[/color]
>
> That is because the parenthesis *only* encode the grouping information,
> they do not do double duty and encode what they are grouping.
> The key here is to realize that the words `DEFUN' and the `IF' themselves
> look very different.[/color]

Well, I'm evidently still not getting it, because my reply would be "and so do
'def ...:' and 'if ...:' in python" (and you also can't tell whether the 8
spaces on the left margin come from a 'def' and and an enclosed 'if' or vice
versa).

[color=blue][color=green][color=darkred]
> >> Yet the visual representation is not only identical between all of these, it
> >> cannot even be displayed.[/color]
> >
> > I don't understand what you mean. Could you maybe give a concrete example of
> > the information that can't be displayed?[/color]
>
> Sure. Here are five parens ))))) How much whitespace is there here:[/color]

10 spaces (which BTW I counted in emacs in just the same way that I'd count a
similar number of parens) -- but what has counting random trailing whitespace
got to do with anything? Apart from the fact that only leading whitespace is
significant in python, I've personally never felt any need to count it -- have
you? I have, however felt the need to count parens from time to time (in
python as well).
[color=blue][color=green]
> >
> > Still, I'm sure you're familiar with the following quote (with which I most
> > heartily agree):
> >
> > "[P]rograms must be written for people to read, and only incidentally for
> > machines to execute."
> >
> > People can't "read" '))))))))'.[/color]
>
> Funny, the people you just quoted would disagree with you about parenthesis.
> I expect that they would disagree with you about whitespace as well.[/color]

Why, do they know someone with a paren-counting brain-implant? If so every
lisper should get one -- no more carpal tunnel syndrome from frantic C-M-\
pressing or alphabet wastage due to scheme-style 'aliasing' of '[...]' to
'(...)'.

Seriously, I really fail to see see what the source of disagreement with the
above statement could be.

If I gave you a piece of lisp code jotted down on paper that (as those
hypothetical examples usually are) for some reason was of vital importance and
that on typing it in revealed a mismatch between the indentation and the
parenthesation in a key section of the code -- which interpretation would you
hedge your bets on in the absence of other indicators; the one suggested by
the indentation or the 9 trailing parens?

Anyway, readability is an overarching but not the only important factor in the
design of language's syntax (you mentioned the ergonomics of editing and there
are of course others), and as I said I think sexps are in fact a rather good
syntax for an expression oriented language.

'as

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

Kenny Tilton wrote:[color=blue]
>
>
> Andrew Dalke wrote:
>[color=green]
>> Kenny Tilton:
>>[color=darkred]
>>> I wouldn't take the Greenspun crack too seriously. That's about
>>> applications recreating Lisp, not languages copying Lisp features.[/color]
>>
>>
>>
>> Are you stating that all references of Greenspun's 10th rule,
>> when applied to Python, are meant in jest?[/color]
>
>
> Can't speak for others, but it certainly would be a mistake to apply it
> to another HLL.
>
>[color=green]
>> Python isn't doing that. It's lives in a perfectly good niche wherein
>> Lisp is not the most appropriate language.[/color]
>
>
> OK, another Pythonista just told me GVR had greater ambitions. Just
> tellin ya what I hear.
>
>
>[color=green][color=darkred]
>>> You presume that only Lisp gurus can learn Lisp because of the syntax.[/color]
>>
>>
>>
>> Not at all. What I said is that Lisp gurus are self-selected to be
>> the ones who don't find the syntax to be a problem. You incorrectly
>> assumed the converse to be true.[/color]
>
>
> No, I got that, but I just wrote it kinda convoluted. And that
> self-selection thing is just silly, until people over here:
>
> http://alu.cliki.net/Kenny's%20RtLS% 20Top-Ten
>
> ...come back in a month and update their responses to say "Drat! That
> language is every bit as great as I thought it was, but that syntax is
> driving me nuts. I'm outtahere!"
>
> Won't happen, btw. Hell, Tolton loved Lisp even before he picked up some
> editing tips.
>
> You know, I just remembered a relevant experience I had, only with a
> very early release of Dylan during the search I conducted which led to
> Common Lisp, aka The Promised Land.
>
> I actually made a bug report to the Dylan team: "hey, when I hit tab the
> cursor jumps way the hell out here, just inside the IF. I mean, that's
> pretty fucking cool if you meant that to happen, but what's going on?"
>
> :)
>
>[color=green]
>>
>>[color=darkred]
>>> But methinks a number of folks using Emacs Elisp and Autocad's embedded
>>> Lisp are non-professionals.[/color]
>>
>>
>>
>> Methinks there are a great many more people using the VBA
>> interface to AutoCAD than its Lisp interface. In fact, my friends
>> (ex-Autodesk) told me that's the case.[/color]
>
>
> Sheesh, who hasn't been exposed to basic? From my generation, that is.
> :) But no matter, the point is anyone can handled parens if they try for
> more than an hour.
>
>[color=green]
>> What does it mean to be "a Lisp"? Is Python considered "a Lisp"
>> for some definitions of Lisp?[/color]
>
>
> lessee:
>
> symbols? no
> sexprs? no
> code as data as code? no
>
> sorry, charlie.
>
>[color=green][color=darkred]
>>> You (Alex?) also worry about groups of programmers and whether what is
>>> good for the gurus will be good for the lesser lights.[/color]
>>
>>
>>
>> If you ever hear me call anyone who is not an expert programmer
>> a "lesser light" then I give you -- or anyone else here -- permission
>> to smack me cross-side the head.[/color]
>
>
> Boy, you sure can read a lot into a casually chosen cliche. But can we
> clear up once and for all whether these genius scientists are or are not
> as good a programmer as you? I thought I heard Python being recommended
> as better for non-professional programmers.
>
> Mind you, to my horror my carefully trained goalie turned out not to
> scale at all into game play (my fault) so i am back to square one with
> two days to go, so maybe I am not following all this as well as I should.
>
>[/color]

I will admit getting those editing key strokes was pretty dang nice.

Although I have been doing my coding in Emacs all along. :)

--
Doug Tolton
(format t "~a@~a~a.~a " "dtolton" "ya" "hoo" "com")

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:[color=blue]
> Pascal Costanza wrote:
> ...
>[color=green][color=darkred]
>>>programmin g languages are NOT "mathematic s", as some claim -- they
>>>are engineering designs, and interact with human minds, sociology
>>>of groups, cultural and educational features, at least as much as
>>>they interact with the architecture and capabilities of computers.[/color]
>>
>>I definitely agree. Computer science is more a sociological science than
>>a natural science IMHO.[/color]
>
>
> Amen, hallelujah. So, since I've decided to limit my participation in this
> thread to c.l.python, would you kindly set right the guys (such as your
> namesake) who (on c.l.lisp with copy to my mailbox but not to here) are
> currently attacking me because, and I quote,
> """
> Software is a department of mathematics.
> """
> ...?[/color]

The context in which this statement was made is not clear to me, so I
don't know what I would actually defend.

I haven't followed all branches of the thread, and the posting that
contains that statement is a reaction to an analogy that I think is not
a good one. I don't want to dive further into this specific branch. Sorry.


Pascal

[Corey Coughlin]

Re: Python syntax in Lisp and Scheme

You are mostly correct about Japanese, I took a year of it in college
and it is a fairly standard SOV language. (Like Latin, oddly enough.)
And I'm sure you're right about RPN vs. PN, I always get those
confused. Which is kind of the point, really, having studied math
since I was a kid I got used to stuff like "y = mx + b", can you
blame me if I have an easier time with "y = m*x + b" as opposed to
"(let y (+ (* m x) b))" (Forgive me if the parenthesis on that are
off, the newsreader editor doesn't match them, and maybe I need a
'setq' instead of a 'let' or some other thing, I'm not entirely sure.)
(And again, is the point getting more clear?) And thanks for backing
me up on car's and cdr's, I never could understand why a language
ostensibly designed for 'list processing' has such a bizarre way to
reference items in a list. But is (nth 10 mylist) really as easy as
mylist[10]? My intuition says no, not really.

Sure, I can appreciate looking at things in different ways, and it is
nice to learn new things and see how they apply. But if John Grisham
learns Japanese, does that mean he should write all his books in
Japanese? Or should he stick to English? I suppose if I were a real
CS guy (I'm actually an electrical engineer, the scheme course was one
of the two CS courses I took in college, so I'm mostly self taught) or
if I worked within a big group of Lisp programmers, I would probably
feel more comfortable with it. Since I now mostly work as an isolated
programmer for other engineers, and the last language I was using for
everything was C, Python is a huge improvement, and it doesn't give me
too much of a headache. Sure, it's not perfect. But there's no way
I'm going to adopt Lisp as a perfect language anytime soon. That is,
if I want to keep hitting my deadlines and getting paid. And sure, I
may get comfortable and miss out on cool stuff, but on the upside,
I'll be comfortable.

Oh, and if I'm writing in this thread, I suppose I should comment on
how bad lisp macros are. Except I know nothing about them. But it
seems like most languages have dark corners like that, where you can
do thing above and beyond your standard programming practices. Python
has metaclasses, which give me a headache most of the time, so I don't
really use them at all. But I seem to get plenty of stuff done
without using them, so it works for me. If you really have to use
macros in Lisp to get things done, that sounds kind of troublesome,
but it would be consistent, it always seemed like really working well
in Lisp requires you to really know how everything works all at once,
which always kind of struck me as kind of a downside. But as I said,
I'm not the big CS guru, so Lisp just may not be for me in general.
Ah well, I suppose I'll get by with Python. :D

Albert Lai <trebla@vex.net > wrote in message news:<4ullrtrdo q.fsf@vex.net>. ..[color=blue]
> corey.coughlin@ attbi.com (Corey Coughlin) writes:
>[color=green]
> > (Not to mention car, cdr, cadr, and
> > so on vs. index notation, sheesh.)[/color]
>
> Yes, that is a real regret. It should have been useful to support
> a kind of (nth 10 mylist) straight from the Scheme standard library.
>[color=green]
> > Using parentheses and rpn everywhere makes lisp very easy
> > to parse, but I'd rather have something easy for me to understand and
> > That's why I prefer python, you
> > get a nice algebraic syntax with infix and equal signs, and it's easy
> > understand.
> > Python is
> > intuitive to me out of the box, and it just keeps getting better, so I
> > think I'll stick with it.[/color]
>
> First, a minor correction: Lisp/Scheme is like (* 1 2) and that is
> Polish Notation or prefix; Reverse Polish Notation or postfix would be
> like (1 2 *).
>
> From what I heard about the Japanese language I have formed the
> possibly oversimplified impression that it is largely postfix.
> Whereas in English we say "I beat you", they may say something like "I
> you beat". So I suppose all of the existing programming notations -
> Lisp's and Cobol's (* 1 2) and MULTIPLY 1 BY 2, Fortran's "intuitive"
> 1+2, and OO's one.add(two) - are very counterintuitiv e to them, and
> they would really like the way of HP calculators, no?
>
> And I suppose the ancient Romans (and even the modern Vaticans) would
> laugh at this entire dilemma (or trilemma?) between ___fixes.
>
> Intuition is acquired. It is purely a product of education or
> brainwashing. There is nothing natural about it. And since it is
> acquired, you may as well keep acquiring new intuitions and see more
> horizons, rather than keep reinforcing old intuitions and stagnate.
> Appreciating a foreign language such as Japanese some day is not a bad
> idea.[/color]

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Pascal Costanza:[color=blue]
> And, as Paul Graham put it, if you take a language and "add that final
> increment of power, you can no longer claim to have invented a new
> language, but only to have designed a new dialect of Lisp". (see
> http://www.paulgraham.com/diff.html )[/color]

What about a language for quantum based computing? I
know the perl folk have a stab at emulating such a language

http://www.perl.com/pub/a/2001/08/08/quantum.html

Are there programming possibilities in manipulating ensembles
of possible expressions? Eg, an O(sqrt(N)) search of all
possible algorithms which solve an optimization problem
might prove interesting.

Hmmm, if a problem can be solved in a language of 32 operators
using, say, 50 of those operators, then it can be found after only
O(sqrt(32**50)) == O(2**30) steps.

I'm sure there are other possibilites which are more realistic though.

The fact that such hardware does not exist shouldn't
be a limitation. Babbage's code worked on a machine that
was never built (*and* it had the potential ability to modify
it's own input, making Lisp a 'dialect' of that ur-language),
and Turing's work was also on a theoretical machine.

But then, I'm just a speaker of a dialect of Proto-Indo-European
and my language hasn't improved on the original over the last
few thousand years. ;)

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Alex Martelli:[color=blue]
> Absolutely! But funding such studies would seem hard. Unless some
> company or group of volunteers had their own reasons to take some
> existing large app coded in Lisp/Python/Perl/Ruby, and recode it in
> one of the other languages with essentially unchanged functionality,[/color]

I keep thinking that the bioperl/biopython/bioruby/biojava code bases
would be a source of data for such a study, but upon just a bit of
thinking I realized that each of the projects has a different way of
dealing with a problem. There is overlap between the two, but even
at the file parsing level, bioperl's approach is different from biojava's
and quite different from biopython's.

Another possibility is the code needed for some cross-platform
standard, like a DOM. That's possible, but I suspect there are
large variations in code size even amoung the Python DOMs,
as well as little likelihood of full compliance by all code bases.

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Alex:[color=blue]
> Well, somebody once asked how
> a Pythonista would go about it -- and the answer was unanimous:
> print "Just another Python hacker"[/color]

It wasn't unanimous. I recall I posted something like
[color=blue][color=green][color=darkred]
>>> class Write:[/color][/color][/color]
.... def __getattr__(sel f, word): print word,; return self
.... def __repr__(self): return ""
....[color=blue][color=green][color=darkred]
>>> Write().Just.an other.Python.ha cker[/color][/color][/color]
Just another Python hacker
[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

;)
[color=blue]
> My perhaps-not-extensive-enough experience with macros showed them
> being used to merge language and meta-language -- in widely different
> ways in different labs or even within a given lab -- while at the
> same time other firms were using languages without macros (APL and
> variants thereof) and processing them with different and separate
> metalanguages AND thereby managing to achieve better (intra-firm, at
> least) cooperation.[/color]

I rather like the phrase I used in private mail: supports mutliple language
paradigm instead of a multiple paradigm language.

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Alex Martelli:[color=blue]
> would you kindly set right the guys (such as your
> namesake) who (on c.l.lisp with copy to my mailbox but not to here) are
> currently attacking me because, and I quote,
> """
> Software is a department of mathematics.
> """[/color]

And anyone who doesn't think mathematics has its own
culture with ideas and even mistaken preferences for what
is right and wrong should read

The Mystery of the Aleph: Mathematics, the Kabbalah, and the Human Mind

to see how Cantor's ideas of transfinite numbers (and other ideas,
as I recall, like showing there are functions which are everywhere
continuous and nowhere differentiable) were solidly rejected by
most other mathematicians of his time.

Mathematicians are people as well.

Andrew
dalke@dalkescie ntific.com

[Matthew Danish]

Re: Python syntax in Lisp and Scheme

On Tue, Oct 07, 2003 at 08:01:37PM +0200, Marcin 'Qrczak' Kowalczyk wrote:[color=blue]
> I find the Lisp syntax hardly readable when everything looks alike,
> mostly words and parentheses, and when every level of nesting requires
> parens. I understand that it's easier to work with by macros, but it's
> harder to work with by humans like I.[/color]

I find the ML/Haskell/infix syntax hardly readable when everything is
visually ambiguous, mostly a jumble of non-alphanumeric characters, and
it is difficult to determine where nesting occurs without looking it up
in a reference. I understand that this gives the code the dubious
distinction of looking a little bit like math notation, perverted into
ASCII, but it's harder to work with by Lisp programmers like myself.


P.S. I've written my fair share of SML, I'd like to think, and while it
could be quite infuriating I did appreciate pattern matching and
currying. Of course, both of these can be done in CL, and more flexibly
too.

--
; Matthew Danish <mdanish@andrew .cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian. org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

[prunesquallor@comcast.net]

Re: Python syntax in Lisp and Scheme

Alexander Schmolck <a.schmolck@gmx .net> writes:
[color=blue]
> [narrowing down to c.l.l and c.l.p]
> prunesquallor@c omcast.net writes:
>[color=green][color=darkred]
>> > Significantly, AFAICT you can easily do this unambiguously and *locally*,
>> > for example your editor can trivially perform this operation on cutting a
>> > piece of python code and its inverse on pasting (so that you only
>> > cut-and-paste the 'local' indentation). Prima facie I don't see how you
>> > loose any fine control.[/color]
>>
>> Only if your cut boundaries are at the same lexical level. If you cut
>> across boundaries, it is no longer clear what should happen at the paste.[/color]
>
> The only unclarity would arise from dedents of more than one level on the
> corner of your cut region, I think.[/color]

Suppose I cut just one arm of a conditional. When I paste, it is
unclear whether I intend for the code after the paste to be part of
that arm, part of the else, or simply part of the same block.
[color=blue][color=green]
>> The fact that the information is replicated, and that there is nothing
>> but programmer discipline keeping it consistent is a source of errors.[/color]
>
> Sure there is. Your editor and immediate visual feedback (no need to remember
> to reindent after making the semantic changes).[/color]

`immediate visual feedback' = programmer discipline
Laxness at this point is a source of errors.
[color=blue][color=green][color=darkred]
>> > I don't understand why this is any different to e.g. ')))))' in Lisp. The
>> > closing ')' for DEFUN just looks the same as that for IF.[/color]
>>
>> That is because the parenthesis *only* encode the grouping information,
>> they do not do double duty and encode what they are grouping.
>> The key here is to realize that the words `DEFUN' and the `IF' themselves
>> look very different.[/color]
>
> Well, I'm evidently still not getting it, because my reply would be "and so do
> 'def ...:' and 'if ...:' in python" (and you also can't tell whether the 8
> spaces on the left margin come from a 'def' and and an enclosed 'if' or vice
> versa).[/color]

I'm not sure I can explain any better, I *think* perhaps some of the other
Lispers might get what I'm saying here.
[color=blue][color=green][color=darkred]
>> >> Yet the visual representation is not only identical between all of these, it
>> >> cannot even be displayed.
>> >
>> > I don't understand what you mean. Could you maybe give a concrete example of
>> > the information that can't be displayed?[/color]
>>
>> Sure. Here are five parens ))))) How much whitespace is there here:[/color]
>
> 10 spaces (which BTW I counted in emacs in just the same way that I'd count a
> similar number of parens) -- but what has counting random trailing whitespace
> got to do with anything?[/color]

It is simply an illustration that there is no obvious glyph associated
with whitespace, and you wanted a concrete example of something that can't
be displayed.
[color=blue][color=green][color=darkred]
>> > Still, I'm sure you're familiar with the following quote (with which I most
>> > heartily agree):
>> >
>> > "[P]rograms must be written for people to read, and only incidentally for
>> > machines to execute."
>> >
>> > People can't "read" '))))))))'.[/color]
>>
>> Funny, the people you just quoted would disagree with you about parenthesis.
>> I expect that they would disagree with you about whitespace as well.[/color]
>
> Why, do they know someone with a paren-counting brain-implant? If so every
> lisper should get one -- no more carpal tunnel syndrome from frantic C-M-\
> pressing or alphabet wastage due to scheme-style 'aliasing' of '[...]' to
> '(...)'.
>
> Seriously, I really fail to see see what the source of disagreement with the
> above statement could be.[/color]

I cannot read Abelson and Sussman's minds, but neither of them are
ignorant of the vast variety of computer languages in the world.
Nonetheless, given the opportunity to choose any of them for
exposition, they have chosen lisp. Sussman went so far as to
introduce lisp syntax into his book on classical mechanics.
Apparently he felt that not only *could* people read ')))))))', but
that it was often *clearer* than the traditional notation.
[color=blue]
> If I gave you a piece of lisp code jotted down on paper that (as those
> hypothetical examples usually are) for some reason was of vital importance and
> that on typing it in revealed a mismatch between the indentation and the
> parenthesation in a key section of the code -- which interpretation would you
> hedge your bets on in the absence of other indicators; the one suggested by
> the indentation or the 9 trailing parens?[/color]

Obviously the indentation. But I'd notice the mismatch.

If I gave you a piece of python code jotted down on paper that (as these
hypothetical examples usually are) for some reason was of vital importance
but I accidentally misplaced the indentation -- how would you know?

[Christos TZOTZIOY Georgiou]

Re: Python syntax in Lisp and Scheme

On Fri, 10 Oct 2003 10:15:35 -0400, rumours say that Joe Marshall
<jrm@ccs.neu.ed u> might have written:
[color=blue][color=green][color=darkred]
>>> I would think Lisp is more like cricket: wickets bracket both ends, no
>>> one can actually understand the rules, but at least the players wear
>>> white.[/color]
>>
>> Oh, come on! Anyone can understand cricket! There are two teams.
>> The team that's in sits out, except for two batsmen, and the other
>> team come out and try to get the men that are in out. When a man goes
>> out, he goes in and another man comes out. When the team that's in
>> are all out, except for the one who's not out, the other team goes in,
>> until they're all out, too; and then a second innings is played.
>> That's more or less all there is to it![/color]
>
>In other words, the man that's in may be out or in. If he's in, he
>can go back out, but if he's out, then he can't go back in. Once
>everyone is out, everyone goes out, then once the in team is out
>again, the out team goes in again and everyone in can go out again.[/color]

This amount of input/output should be a responsibility of the operating
system.
--
TZOTZIOY, I speak England very best,
Ils sont fous ces Redmontains! --Harddix

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:
[color=blue]
> Alex Martelli:[color=green]
>> would you kindly set right the guys (such as your
>> namesake) who (on c.l.lisp with copy to my mailbox but not to here) are
>> currently attacking me because, and I quote,
>> """
>> Software is a department of mathematics.
>> """[/color]
>
> And anyone who doesn't think mathematics has its own
> culture with ideas and even mistaken preferences for what
> is right and wrong should read
>
> The Mystery of the Aleph: Mathematics, the Kabbalah, and the Human Mind
>
> to see how Cantor's ideas of transfinite numbers (and other ideas,
> as I recall, like showing there are functions which are everywhere
> continuous and nowhere differentiable) were solidly rejected by
> most other mathematicians of his time.
>
> Mathematicians are people as well.[/color]

Your point is very well taken, and I should have made it myself; Kuhn's
"Structure of Scientific Revolutions" applies to maths just as well as to
other sciences (even though I wasn't aware of your specific reference --
and I'm ordering it right now:-).

But, there's more: maths is emphatically NOT only done by mathematicians;
and the favourite languages and notations used by other scientists and
technicians to speak maths *often differ by field*, all the way down to
silly little lexical quibbles such as using j or i to denote sqrt(-1) .

So, even if software WAS mostly about maths, rather than mostly about
interactions among human beings, this *still* wouldn't suggest that a single
programming language "good for all uses" should be adopted instead of
following a "horses for courses" approach.


Alex