Python syntax in Lisp and Scheme

[Alexander Schmolck]

Re: Python syntax in Lisp and Scheme

Joe Marshall <jrm@ccs.neu.ed u> writes:

[color=blue]
> Alexander Schmolck <a.schmolck@gmx .net> writes:
>[color=green]
> > prunesquallor@c omcast.net writes:[/color]
> (I'm ignoring the followup-to because I don't read comp.lang.pytho n)[/color]

Well, I supposed this thread has spiralled out of control already anyway:)
[color=blue]
> Indentation-based grouping introduces a context-sensitive element into
> the grammar at a very fundamental level. Although conceptually a
> block is indented relative to the containing block, the reality of the
> situation is that the lines in the file are indented relative to the
> left margin. So every line in a block doesn't encode just its depth
> relative to the immediately surrounding context, but its absolute
> depth relative to the global context.[/color]

I really don't understand why this is a problem, since its trivial to
transform python's 'globally context' dependent indentation block structure
markup into into C/Pascal-style delimiter pair block structure markup.

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=blue]
> Additionally, each line encodes this information independently of the other
> lines that logically belong with it, and we all know that when some data is
> encoded in one place may be wrong, but it is never inconsistent.[/color]

Sorry, I don't understand this sentence, but maybe you mean that the potential
inconsitency between human and machine interpretation is a *feature* for Lisp,
C, Pascal etc!? If so I'm really puzzled.
[color=blue]
> There is yet one more problem. The various levels of indentation encode
> different things: the first level might indicate that it is part of a
> function definition, the second that it is part of a FOR loop, etc. So on
> any line, the leading whitespace may indicate all sorts of context-relevant
> information.[/color]

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=blue]
> 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? AFAICT you can have 'sexp'-movement,
markup and highlighting commands all the same with whitespace delimited block
structure.
[color=blue]
>
> Is this worse than C, Pascal, etc.? I don't know.[/color]

I'm pretty near certain it is better: In Pascal, C etc. by and large block
structure delimitation is regulated in such a way that what has positive
information content for the human reader/programmer (indentation) has zero to
negative information content for the compiler and vice versa. This is a
remarkably bad design (and apart from cognitive overhead obviously also causes
errors).

Python removes this significant problem, at as far as I'm aware no real cost
and plenty of additional gain (less visual clutter, no waste of delimiter
characters ('{','}') or introduction of keywords that will be sorely missed as
user-definable names ('begin', 'end')).

In Lisp the situtation isn't quite as bad, because although most of the parens
are of course mere noise to a human reader, not all of them are and because of
lisp's simple but malleable syntactic structure a straighforward replacement
of parens with indendation would obviously result in unreadable code
(fragmented over countless lines and mostly in past the 80th column :).

So unlike C and Pascal where a fix would be relatively easy, you would need
some more complicated scheme in the case of Lisp and I'm not at all sure it
would be worth the hassle (especiallly given that efforts in other areas would
likely yield much higher gains).

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=blue]
> Worse than Lisp, Forth, or Smalltalk? Yes.[/color]

Possibly, but certainly not due to the use of significant whitespace.


'as

[Alexander Schmolck]

Re: Python syntax in Lisp and Scheme

Marco Antoniotti <marcoxa@cs.nyu .edu> writes:
[color=blue]
> The best choice for code indentation in any language is M-C-q in Emacs.[/color]

You mean C-c> and C-c<.

'as

[Alexander Schmolck]

Re: Python syntax in Lisp and Scheme

Marco Antoniotti <marcoxa@cs.nyu .edu> writes:
[color=blue]
> Why do I feel like crying? :{[/color]

Could it be because you've actually got some rational argument against
significant whitespace a la python?!

'as

[Dirk Thierbach]

Re: Python syntax in Lisp and Scheme

james anderson <james.anderson @setf.de> wrote:[color=blue]
> Matthias Blume wrote:[/color]
[color=blue][color=green]
>> Most of the things that macros can do can be done with HOFs with just
>> as little source code duplication as with macros. (And with macros
>> only the source code does not get duplicated, the same not being true
>> for compiled code. With HOFs even executable code duplication is
>> often avoided -- depending on compiler technology.)[/color][/color]
[color=blue]
> is the no advantage to being able to do either - or both - as the
> occasion dictates?[/color]

I can't parse this sentence, but of course you can also use HOFs in Lisp
(all flavours). The interesting part is that most Lisp'ers don't seem
to use them, or even to know that you can use them, and use macros instead.

The only real advantage of macros over HOFs is that macros are guaranteed
to to executed at compile time. A good optimizing compiler (like GHC
for Haskell) might actually also evaluate some expressions including
HOFs at compile time, but you have no control over that.
[color=blue]
> i'd be interested to read examples of things which are better done
> with HOF features which are not available in CL.[/color]

HOFs can of course be used directly in CL, and you can use macros to
do everything one could use HOFs for (if you really want).

The advantage of HOFs over macros is simplicity: You don't need additional
language constructs (which may be different even for different Lisp
dialects, say), and other tools (like type checking) are available for
free; and the programmer doesn't need to learn an additional concept.

- Dirk

[Thomas F. Burdick]

Re: Python syntax in Lisp and Scheme

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> writes:
[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]

You find delimited words more difficult than symbols? For literate
people who use alphabet-based languages, I find this highly suspect.
Maybe readers of only ideogram languages might have different
preferences, but we are writing in English here...

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

On Mon, 06 Oct 2003 17:12:18 GMT, Alex Martelli <aleax@aleax.it >
wrote:
[color=blue]
>Imagine a group of, say, a dozen programmers, working together by
>typical Agile methods to develop a typical application program of
>a few tens of thousands of function points -- developing about
>100,000 new lines of delivered code plus about as much unit tests,
>and reusing roughly the same amount of code from various libraries,
>frameworks, packages and modules obtained from the net and/or from
>commercial suppliers. Nothing mind-boggling about this scenario,
>surely -- it seems to describe a rather run-of-the-mill case.
>
>Now, clearly, _uniformity_ in the code will be to the advantage
>of the team and of the project it develops. Extreme Programming
>makes a Principle out of this (no "code ownership"), but even if
>you don't rate it quite that highly, it's still clearly a good
>thing. Now, you can impose _some_ coding uniformity (within laxer
>bounds set by the language) _for code originally developed by the
>team itself_ by adopting and adhering to team-specific coding
>guidelines; but when you're reusing code obtained from outside,
>and need to adopt and maintain that code, the situation is harder.
>Either having that code remain "alien", by allowing it to break
>all of your coding guidelines; or "adopting" it thoroughly by,
>in practice, rewriting it to fit your guidelines; is a serious
>negative impact on the team's productivity.[/color]

Alex, this is pure un-mitigated non-sense. Python's Metaclasses are
far more dangerous than Macro's. Metaclasses allow you to globally
change the underlying semantics of a program. Macros only allow you
to locally change the Syntax. Your comparison is spurious at best.

Your argument simply shows a serious mis-understanding of Macros.
Macros as has been stated to you *many* times are similar to
functions. They allow a certain type of abstraction to remove
extraneous code.

Based on your example you should be fully campaigning against
Metaclasses, FP constructs in python and Functions as first class
objects. All of these things add complexity to a given program,
however they also reduce the total number of lines. Reducing program
length is to date the only effective method I have seen of reducing
complexity.

If you truly believe what you are saying, you really should be
programming in Java. Everything is explicit, and most if not all of
these powerful constructs have been eschewed, because programmers are
just too dumb to use them effectively.


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

[Marcin 'Qrczak' Kowalczyk]

Re: Python syntax in Lisp and Scheme

On Tue, 07 Oct 2003 21:59:11 +0200, Pascal Bourguignon wrote:
[color=blue]
> When you have macros such as loop that allow you to write stuff like:
>
> (loop for color in '(blue white red)[/color]
[...]

Well, some people say the "loop" syntax is not very lispish - it's unusual
that it uses many words and few parentheses. It still uses only words and
parentheses, no other punctuation, and it introduces one pair of parentheses
for its one nesting level.

A richer alphabet is often more readable. Morse code can't be read as fast
as Latin alphabet because it uses too few different symbols. Japanese say
they won't abandon Kanji because it's more readable as soon as you know it -
you don't have to compose words from many small pieces which look alike
but each word is distinct. Of course *too* large alphabet requires long
learning and has technical difficulties, but Lisp expressions are too
little distinctive for my taste.

I know I can implement infix operators with Lisp macros, but I even don't
know how they feel because nobody uses them (do I have to explicitly open
infix region and explicitly escape from it to regular syntax?), and
arithmetic is not enough. All Lisp code I've read uses lots of parentheses
and they pile up at the end of each large subexpression so it's hard to
match them (an editor is not enough, it won't follow my eyes and won't
work with printed code).

Syntax is the thing I like the least in Lisp & Scheme.

--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org. pl
^^ http://qrnik.knm.org.pl/~qrczak/

[Corey Coughlin]

Re: Python syntax in Lisp and Scheme

I was never very fond of lisp. I guess I mean scheme technically, I
took the Ableson and Sussman course back in college, so that's what I
learned of scheme, lisp in general I've mostly used embedded in other
things. In general, it always seemed to me that a lot of the design
choices in lisp are driven more by elegance and simplicity than
usability. When it comes to programming languages, I really want the
language to be a good tool, and to do as much of the work for me as
possible. Using parentheses and rpn everywhere makes lisp very easy
to parse, but I'd rather have something easy for me to understand and
hard for the computer to parse. (Not to mention car, cdr, cadr, and
so on vs. index notation, sheesh.) That's why I prefer python, you
get a nice algebraic syntax with infix and equal signs, and it's easy
understand. Taking out ';' at the ends of lines and indenting for
blocks helps me by removing the clutter and letting me see the code.
And yes, I'm sure you can write macros in lisp to interpret infix
operators and indexing and whatever you want, but learning a core
language that's wildly non-intuitive so that I can make it more
intuitive never seemed like a good use of my time. Python is
intuitive to me out of the box, and it just keeps getting better, so I
think I'll stick with it.

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

On 7 Oct 2003 12:59:07 -0700, hanzspam@yahoo. com.au (Hannu Kankaanp??)
wrote:
[color=blue]
>prunesquallor@ comcast.net wrote in message news:<8ynx6tb1. fsf@comcast.net >...[color=green]
>> hanzspam@yahoo. com.au (Hannu Kankaanp??) writes:[color=darkred]
>> > So getting to the point, doesn't the example show that indentation
>> > is in fact a *good* choice for block delimiting? It's an alternative that
>> > wouldn't have the subtle bug you introduced here. So how can you
>> > claim that this example shows indentation is a poor choice for block
>> > delimiting? It doesn't make sense.[/color]
>>
>> The point was that even though I screwed up the indentation, it was
>> easily discovered and repaired with Emacs. If the program were
>> whitespace-sensitive, then the screwed-up version would be
>> mechanically indistinguishab le from the intended one.[/color][/color]
[color=blue]
>How do you "screw up indentation"? Actually, being more of a
>Python fan, I though you had screwed up parens, since indentation
>is absolute for me :). Anyway, do you just go to some line and start
>pressing spacebar randomly, and not notice this? Maybe
>you do need a safety net, then.
>[/color]

Maybe by coding in an environment with multiple programmers?
Alex was saying that Python's syntax and simplicity is so much better
for large scale projects with multiple programmers. With just 4
programmers using Python at work we have problems with indentation
levels. One guy (me) uses emacs, another uses ultra-edit, another
uses Boa and the other uses PythonWin. Indenting can be a major
source of compilation bugs.
[color=blue]
>But the whitespace already has all the structural information needed.
>The whitespace doesn't just disappear suddenly, much like parens don't
>magically disappear or mutate.
>
>There can be problems in cutting and pasting code if one mixes tabs
>and spaces, like Ingvar said, but generally the rule in Python is to
>use 4 spaces for each indentation level. If you break this rule,
>you know you had it coming when something fails ;).[/color]

Just because it's defined that way, doesn't make it less a pain in the
ass to fix the problems.

of course it's not a big problem if you are the only consumer of your
code.


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

[Eli Barzilay]

Re: Python syntax in Lisp and Scheme

Matthias Blume <find@my.addres s.elsewhere> writes:
[color=blue]
> raffael@mediaon e.net (Raffael Cavallaro) writes:
>[color=green]
> > Two words: code duplication.[/color]
>
> Three words and a hyphen: Higher-Order Functions.[/color]

This covers most usages of macros for control structures, but not
all. (For example, goto.)

But there is an additional word to add, no hyphens: Bindings.

[color=blue][color=green]
> > This can only be accomplished with functions if you're willing to
> > write a set of functions that defer evaluation, by, say parsing
> > input, massaging it appropriately, and then passing it to the
> > compiler. At that point, however, you've just written your own
> > macro system, and invoked Greenspun's 10th Law.[/color]
>
> This is false. Writing your own macro expander is not necessary for
> getting the effect. The only thing that macros give you in this
> regard is the ability to hide the lambda-suspensions. To some
> people this is more of a disadvantage than an advantage because,
> when not done in a very carefully controlled manner, it ends up
> obscuring the logic of the code. (Yes, yes, yes, now someone will
> jump in an tell me that it can make code less obscure by "canning"
> certain common idioms. True, but only when not overdone.)[/color]

(This hits one of the major differences between Lisp and Scheme -- in
Lisp I'm not as happy to use HOFs because of the different syntax
(which is an indication of a different mindset, which leads to
performance being optimized for a certain style). Scheme is much more
functional in this respect, for example -- using HOF versions of
with-... compared to Lisp where these are always macros.)

--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!

[james anderson]

Re: Python syntax in Lisp and Scheme



Eli Barzilay wrote:[color=blue]
>
> Matthias Blume <find@my.addres s.elsewhere> writes:
>
> ...[color=green]
> >
> > This is false. Writing your own macro expander is not necessary for
> > getting the effect. The only thing that macros give you in this
> > regard is the ability to hide the lambda-suspensions. To some
> > people this is more of a disadvantage than an advantage because,
> > when not done in a very carefully controlled manner, it ends up
> > obscuring the logic of the code. (Yes, yes, yes, now someone will
> > jump in an tell me that it can make code less obscure by "canning"
> > certain common idioms. True, but only when not overdone.)[/color]
>
> (This hits one of the major differences between Lisp and Scheme -- in
> Lisp I'm not as happy to use HOFs because of the different syntax[/color]

which difference differnt syntax?
[color=blue]
> (which is an indication of a different mindset, which leads to
> performance being optimized for a certain style). Scheme is much more
> functional in this respect, for example -- using HOF versions of
> with-... compared to Lisp where these are always macros.)[/color]

in practice, as a rule, a with- is available at least optionally also as a
call-with-. not just for convenience, but also for maintainability .

in the standard there are but twelve of these. should they be an impediment,
in most cases there is nothing preventing one from writing call-with-...
equivalents. many expand fairly directly to special forms, so they are even
trivial to reimplement if the "double-nesting" were distasteful. i am curious,
however, about the HOF equivalents for macros which expand primarily to
changes to the lexical environment. not everything has a ready equivalence to
lambda. for instance with-slots and with-accessors. what is the HOF equivalent
for something like

? (defclass c1 () ((s1 )))

#<STANDARD-CLASS C1>
? (defmethod c1-s1 ((instance c1))
(with-slots (s1) instance
(if (slot-boundp instance 's1)
s1
(setf s1 (get-universal-time)))))

#<STANDARD-METHOD C1-S1 (C1)>
? (defparameter *c1* (make-instance 'c1))

*C1*
? (describe *c1*)
#<C1 #x69D95C6>
Class: #<STANDARD-CLASS C1>
Wrapper: #<CCL::CLASS-WRAPPER C1 #x69D95A6>
Instance slots
S1: #<Unbound>
? (c1-s1 *c1*)
3274553173
? (describe *c1*)
#<C1 #x69D95C6>
Class: #<STANDARD-CLASS C1>
Wrapper: #<CCL::CLASS-WRAPPER C1 #x69D95A6>
Instance slots
S1: 3274553173
?

[Eli Barzilay]

Re: Python syntax in Lisp and Scheme

james anderson <james.anderson @setf.de> writes:
[color=blue]
> Eli Barzilay wrote:[color=green]
> >
> > (This hits one of the major differences between Lisp and Scheme --
> > in Lisp I'm not as happy to use HOFs because of the different
> > syntax[/color]
>
> which difference differnt syntax?[/color]

Huh?

[color=blue][color=green]
> > (which is an indication of a different mindset, which leads to
> > performance being optimized for a certain style). Scheme is much more
> > functional in this respect, for example -- using HOF versions of
> > with-... compared to Lisp where these are always macros.)[/color]
>
> in practice, as a rule, a with- is available at least optionally also as a
> call-with-. not just for convenience, but also for maintainability .
> [...][/color]

Yes, but I was talking about the difference approaches, for example:

(dolist (x foo)
(bar x))

vs:

(mapc #'bar foo)

[color=blue]
> i am curious, however, about the HOF equivalents for macros which
> expand primarily to changes to the lexical environment. [...][/color]

That was the point I made in the beginning.

--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!

[james anderson]

Re: Python syntax in Lisp and Scheme



Eli Barzilay wrote:[color=blue]
>
> james anderson <james.anderson @setf.de> writes:
>[color=green]
> > Eli Barzilay wrote:[color=darkred]
> > >
> > > (This hits one of the major differences between Lisp and Scheme --
> > > in Lisp I'm not as happy to use HOFs because of the different
> > > syntax[/color]
> >
> > which different [] syntax?[/color]
>
> Huh?[/color]

that is, what is different about the syntax for higher-order functions in lisp?
[color=blue]
>[color=green][color=darkred]
> > > (which is an indication of a different mindset, which leads to
> > > performance being optimized for a certain style). Scheme is much more
> > > functional in this respect, for example -- using HOF versions of
> > > with-... compared to Lisp where these are always macros.)[/color]
> >
> > in practice, as a rule, a with- is available at least optionally also as a
> > call-with-. not just for convenience, but also for maintainability .
> > [...][/color]
>
> Yes, but I was talking about the difference approaches, for example:
>
> (dolist (x foo)
> (bar x))
>
> vs:
>
> (mapc #'bar foo)[/color]

are these not two examples of coding in common-lisp. how do they demonstrate
that "scheme is much more functional"?
[color=blue]
>[color=green]
> > i am curious, however, about the HOF equivalents for macros which
> > expand primarily to changes to the lexical environment. [...][/color]
>
> That was the point I made in the beginning.[/color]

sorry, i missed that.

[Peter Seibel]

Re: Python syntax in Lisp and Scheme

corey.coughlin@ attbi.com (Corey Coughlin) writes:
[color=blue]
> Using parentheses and rpn everywhere makes lisp very easy to parse,
> but I'd rather have something easy for me to understand and hard for
> the computer to parse.[/color]

That would be a strong argument--seriously--if the only folks who
benefited from the trivial mapping between Lisp's surface syntax and
underlying were the compiler writers. I certainly agree that if by
expending some extra effort once compiler writers can save their users
effort every time they write a program that is a good trade off.

If the only thing a "regular" programmer ever does with a language's
syntax is read and write it, then the only balance to be struck is
between the perhaps conflicting goals of readability and writability.
(For instance more concise code may be more "writable" but taken to an
extreme it may be "write only".) But "machine parsability" beyond,
perhaps, being amennable to normal machine parsing techniques (LL,
LALR, etc.) should not be a consideration. So I agree with you.

But Lisp's syntax is not the way it is to make the compiler writer's
job easier. In Lisp "regular" programmers also interact with the code
as data. We can easily write code generators (i.e. macros) that are
handed a data representation of some code, or parts of code, and have
only to return a new data structure representing the generated code.
This is such a useful technique that it's built into the compiler--it
will run our code generators when it compiles our code so we don't
have to screw around figuring out how to generate code at runtime and
get it loaded into our program. *That's* why we don't mind, and, in
fact, actively like, Lisp's syntax.

The point is not that the syntax, taking in total isolation from the
rest of the language, is necessarily the best of all possible syntaxi.
The point is that the syntax makes other things possible that *way*
outweigh whatever negatives the syntax may have.

I'd humbly suggest that if you can't see *any* reason why someone
would prefer Lisp's syntax, then you're not missing some fact about
the syntax itself but about how other language features are supported
by the syntax.

-Peter

--
Peter Seibel peter@javamonke y.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

[james anderson]

Re: Python syntax in Lisp and Scheme



Dirk Thierbach wrote:[color=blue]
>
> james anderson <james.anderson @setf.de> wrote:[color=green]
> > Matthias Blume wrote:[/color]
>[color=green][color=darkred]
> >> Most of the things that macros can do can be done with HOFs with just
> >> as little source code duplication as with macros. (And with macros
> >> only the source code does not get duplicated, the same not being true
> >> for compiled code. With HOFs even executable code duplication is
> >> often avoided -- depending on compiler technology.)[/color][/color]
>[color=green]
> > is the no advantage to being able to do either - or both - as the
> > occasion dictates?[/color]
>
> I can't parse this sentence,[/color]

sorry:[color=blue][color=green]
> > is the[re] no advantage to being able to do either - or both - as the
> > occasion dictates?[/color][/color]

[color=blue]
> but of course you can also use HOFs in Lisp
> (all flavours). The interesting part is that most Lisp'ers don't seem
> to use them, or even to know that you can use them, and use macros instead.
>[/color]

while the first assertion might well be born out by a statistical analysis of,
for example, open-source code, i'm curious how one reaches the second conclusion.
[color=blue]
> The only real advantage of macros over HOFs is that macros are guaranteed
> to to executed at compile time. A good optimizing compiler (like GHC
> for Haskell) might actually also evaluate some expressions including
> HOFs at compile time, but you have no control over that.
>[color=green]
> > i'd be interested to read examples of things which are better done
> > with HOF features which are not available in CL.[/color]
>
> HOFs can of course be used directly in CL, and you can use macros to
> do everything one could use HOFs for (if you really want).[/color]

that's a disappointment.
[color=blue]
>
> The advantage of HOFs over macros is simplicity: You don't need additional
> language constructs[/color]

when did common-lisp macros become an "additional language construct"?
[color=blue]
> (which may be different even for different Lisp
> dialects, say), and other tools (like type checking) are available for
> free; and the programmer doesn't need to learn an additional concept.[/color]

doesn't that last phrase contradict the previous one?

i do admit to infrequent direct use of higher-order functions. one reason is
that there is little advantage to articulating the creation of functions which
have dynamic extent only, so in my use, most hof's are manifest through a
macro interface. it's the same distaste i have about inner and anonymous java
classes. the other reason is that when i moved from scheme to lisp, in the
process of porting the code which i carried over, it occurred to me that much
of what i was using higher-order functions for could be expressed more clearly
with abstract classes and appropriately defined generic function method combinations.

....