Python syntax in Lisp and Scheme

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Corey Coughlin wrote:[color=blue]
> 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.[/color]

You should give Common Lisp a try. Many Lispers think that that's
exactly one of the advantages of Common Lisp over Scheme: it focuses
more on usability than on elegance.

Of course, mileages vary, but you shouldn't draw conclusions about
Common Lisp from your experience with Scheme, and vice versa. Common
Lisp and Scheme are as similar as, say, C++ and Pascal.


Pascal

[Eli Barzilay]

Re: Python syntax in Lisp and Scheme

james anderson <james.anderson @setf.de> writes:
[color=blue]
> Eli Barzilay wrote:[color=green]
> >
> > james anderson <james.anderson @setf.de> writes:
> >[color=darkred]
> > > Eli Barzilay wrote:
> > > >
> > > > (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 different [] syntax?[/color]
> >
> > Huh?[/color]
>
> that is, what is different about the syntax for higher-order
> functions in lisp?[/color]

funcall, function, #', the double namespace.

[color=blue][color=green]
> > 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]

The first is very popular, the second is hardly known. R5RS has
`for-each' which is exactly like `mapc', but no `dolist' equivalent.
In Scheme, this is not a problem, in Lisp, the syntax makes me worry
for the extra effort in creating a closure.

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

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> writes:
[color=blue]
> On Tue, 07 Oct 2003 21:59:11 +0200, Pascal Bourguignon wrote:
>[color=green]
> > 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.[/color]

Yes. The point is that the language is rather agnostic about any
topic, even about the syntax. Personnaly I don't like much LOOP, but
I take it as an example by the language designers showing us that it's
even possioble to avoid parethensis if you don't want them.

[color=blue]
> 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.[/color]

Well, I would say that kanji is badly designed, compared to latin
alphabet. The voyels are composed with consones (with diacritical
marks) and consones are written following four or five groups with
additional diacritical marks to distinguish within the groups. It's
more a phonetic code than a true alphabet.

[color=blue]
> 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.[/color]

Most probably, you would write a macro named WITH-INFIX and thus
automatically scope the infix part:

(with-infix 1 / x + 1 / ( x ^ 3 ) + 1 / ( x ^ 5 ) )

and if you write it well:

(with-infix
if a = b then format t "equal ~D~%" a ;
else format t "diff ~D /= ~D~%" a b ; endif ;
for i = 1 to 10 ; print i ; next i )

[color=blue]
> 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.[/color]

I'll tell you the secret: yes there are alot of parethesis. This is a
price all lispers pay for greater benefits. It gives us such
advantages that we gladly pay the price.

Otherwise, I would say:

1- don't pay so much attention to the parenthesis!

2- if you have to and it's hard, then it means the code is badly
structured (probably too big a function). Rewrite it, factorize.

3- what do you mean "printed"? A double-click on any parenthesis
selects the enclosed list so it's quite easy to see what it encloses.



--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

Do not adjust your mind, there is a fault in reality.

[james anderson]

Re: Python syntax in Lisp and Scheme



Eli Barzilay wrote:[color=blue]
>
> ...
>[color=green][color=darkred]
> > > 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]
>
> The first is very popular, the second is hardly known.[/color]

somehow i wonder if we're discussing the same language.
[color=blue]
> R5RS has
> `for-each' which is exactly like `mapc', but no `dolist' equivalent.
> In Scheme, this is not a problem, in Lisp, the syntax makes me worry
> for the extra effort in creating a closure.
>[/color]

what me worry? about syntax?

? (defmacro Barzilay (type operator &rest lists)
`(map ',type (function ,operator) ,@lists))
BARZILAY
? (BARZILAY vector evenp '(1 2 3 4))
#(NIL T NIL T)
? (defmacro Barzilac (operator &rest lists)
`(mapc (function ,operator) ,@lists))
BARZILAC
? (Barzilac (lambda (x) (print x)) '(1 2 3 4))

1
2
3
4
(1 2 3 4)
? (defmacro Barzilar (operator &rest lists)
`(mapcar (function ,operator) ,@lists))
BARZILAR
? (Barzilar + '(1 2 3 4) '(5 6 7 8))
(6 8 10 12)
?

....

[prunesquallor@comcast.net]

Re: Python syntax in Lisp and Scheme

Alexander Schmolck <a.schmolck@gmx .net> writes:
[color=blue]
> Joe Marshall <jrm@ccs.neu.ed u> writes:
>
>[color=green]
>> Alexander Schmolck <a.schmolck@gmx .net> writes:
>>[color=darkred]
>> > 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=green]
>> 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.[/color]

Of course it can. Any unambiguous grammar has a parse tree.
[color=blue]
> 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.

Also, it is frequently the case that you need to `tweak' the code after
you paste it.
[color=blue][color=green]
>> 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]

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.

If, instead, you use balanced delimiters, then a subexpression no
longer has to encode its position within the containing expression.

Let me demonstrate the isomorphism. A simple python expression:
(grrr.. I cut and paste it, but it lost its indentation between
the PDF file and Emacs. I hope I redo it right...)

def index(directory ):
# like os.listdir, but traverses directory trees
stack = [directory]
files = []
while stack:
directory = stack.pop()
for file in os.listdir(dire ctory):
fullname = os.path.join(di rectory, file)
files.append(fu llname)
if os.path.isdir(f ullname) and not os.path.islink( fullname):
stack.append(fu llname)
return files

Now the reason we know that ` files.append(fu llname)' and
` fullname = os.path.join(di rectory, file)' are part of the
same block is because they both begin with 12 spaces. The first
four spaces encode the fact that they belong to the same function,
the next four indicate that they belong in the while loop, and
the final four indicate that they belong in the for loop.
The ` return files', on the other hand, only has four spaces, so
it cannot be part of the while or for loop, but it is still part
of the function. I can represent this same information as a code:

t -def index(directory ):
d - # like os.listdir, but traverses directory trees
d - stack = [directory]
d - files = []
d - while stack:
dw - directory = stack.pop()
dw - for file in os.listdir(dire ctory):
dwf - fullname = os.path.join(di rectory, file)
dwf - files.append(fu llname)
dwf - if os.path.isdir(f ullname) and not os.path.islink( fullname):
dwfi- stack.append(fu llname)
d - return files

The letter in front indicates what lexical group the line belongs to. This
is simply a different visual format for the leading spaces.

Now, suppose that I wish to protect the body of the while statement
within a conditional. Simply adding the conditional won't work:

d - while stack:
dw - if copacetic():
dw - directory = stack.pop()
dw - for file in os.listdir(dire ctory):
dwf - fullname = os.path.join(di rectory, file)
dwf - files.append(fu llname)
dwf - if os.path.isdir(f ullname) and not os.path.islink( fullname):
dwfi- stack.append(fu llname)

because the grouping information is replicated on each line, I have to
fix this information in the six different places it is encoded:

d - while stack:
dw - if copacetic():
dwi - directory = stack.pop()
dwi - for file in os.listdir(dire ctory):
dwif - fullname = os.path.join(di rectory, file)
dwif - files.append(fu llname)
dwif - if os.path.isdir(f ullname) and not os.path.islink( fullname):
dwifi- stack.append(fu llname)

The fact that the information is replicated, and that there is nothing
but programmer discipline keeping it consistent is a source of errors.
[color=blue][color=green]
>> 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]

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=blue][color=green]
>> 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=blue]
>
> 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.

[prunesquallor@comcast.net]

Re: Python syntax in Lisp and Scheme

james anderson <james.anderson @setf.de> writes:
[color=blue][color=green]
>>
>> 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]

That's what macros do: they add new language constructs.

I think that many Scheme students inadvertantly get taught `macros = evil'.
[color=blue]
> 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.[/color]

I also think that many Scheme students are mislead and inadvertantly
taught that one should avoid everything but LAMBDA.

[prunesquallor@comcast.net]

Re: Python syntax in Lisp and Scheme

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> Corey Coughlin wrote:[color=green]
>> 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.[/color]
>
> You should give Common Lisp a try. Many Lispers think that that's
> exactly one of the advantages of Common Lisp over Scheme: it focuses
> more on usability than on elegance.[/color]

S&ICP (Abelson and Sussman) use Scheme to illustrate basic concepts by
stripping away things to get at the core of what's going on. But I
think too many people assume that the stripped-down version is
supposed to be `better' in some sense. (Other than the pedagogic
sense, that is.)

It is like learning about internal combustion engines by disassembling
a lawnmower. It is a very simple illustration of everything important
about 4-stroke engines. However, no one would suggest you actually
build a car that way!

[Tim Hochberg]

Re: Python syntax in Lisp and Scheme

Pascal Bourguignon wrote:[color=blue]
> Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> writes:
>
>[color=green]
>>On Tue, 07 Oct 2003 21:59:11 +0200, Pascal Bourguignon wrote:[/color][/color]
[SNIP][color=blue][color=green]
>>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.[/color]
>
>
> Well, I would say that kanji is badly designed, compared to latin
> alphabet. The voyels are composed with consones (with diacritical
> marks) and consones are written following four or five groups with
> additional diacritical marks to distinguish within the groups. It's
> more a phonetic code than a true alphabet.[/color]
[SNIP]

Admittedly, I found the above paragraph pretty hard to parse and my
never stellar knowledge of Japanees has mostly evaporated over time, but
I'm pretty sure you are talking about Hiragana (or Katakana), not Kanji.
Japaneese has three alphabets, which they mix and match in ordinary
writing. Kanji aren't phonetic at all, they're ideograms, and can
typically be read at least two completely different ways depending on
the context, making reading Japanese extra confusing for the non fluent.

A random web search supplies this basic descripion of Hiragana, Katakana
and Kanji:

http://www.kanjisite.com/html/wak/wak1.html

-tim

[Eli Barzilay]

Re: Python syntax in Lisp and Scheme

james anderson <james.anderson @setf.de> writes:
[color=blue]
> Eli Barzilay wrote:[color=green]
> >[color=darkred]
> > > > Yes, but I was talking about the difference approaches, for
> > > > example:
> > > >
> > > > (dolist (x foo)
> > > > (bar x))
> > > >
> > > > vs:
> > > >
> > > > (mapc #'bar foo)
> > >
> > > are these not two examples of coding in common-lisp. how do they
> > > demonstrate that "scheme is much more functional"?[/color]
> >
> > The first is very popular, the second is hardly known.[/color]
>
> somehow i wonder if we're discussing the same language.[/color]

These are both Lisp examples. The first is much more popular than the
second. Scheme has an equivalent for the second, not for the first.

Conclusion: the first one is stylistically preferred in Lisp, the
(equivalent of the) second is stylistically preferred in Scheme.

[color=blue][color=green]
> > R5RS has `for-each' which is exactly like `mapc', but no `dolist'
> > equivalent. In Scheme, this is not a problem, in Lisp, the syntax
> > makes me worry for the extra effort in creating a closure.[/color]
>
> what me worry? about syntax?
> [...][/color]

You completely missed my point.

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

[Hartmann Schaffer]

Re: Python syntax in Lisp and Scheme

In article <xcvpth8rcfh.fs f@famine.ocf.be rkeley.edu>,
tfb@famine.OCF. Berkeley.EDU (Thomas F. Burdick) writes:[color=blue]
> Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> writes:
>[color=green]
>> 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...[/color]

well, there are a few occasions where symbols are preferrable. just
imagine mathematics with words only

hs

--

ceterum censeo SCO esse delendam

[Lulu of the Lotus-Eaters]

Re: Python syntax in Lisp and Scheme

| 3- what do you mean "printed"? A double-click on any parenthesis
| selects the enclosed list so it's quite easy to see what it encloses.

I kept clicking on the parenthesis in all your samples. All my
newsreader did was go to text-select mode!

Btw. I believe the word "printed" means "printed".. . you've seen that
stuff where ink is applied to paper, yes?

Yours, Lulu...

--
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <mertz@gnosis.c x> ]--------------------------

[prunesquallor@comcast.net]

Re: Python syntax in Lisp and Scheme

Pascal Bourguignon <spam@thalassa. informatimago.c om> writes:
[color=blue]
> Most probably, you would write a macro named WITH-INFIX and thus
> automatically scope the infix part:
>
> (with-infix 1 / x + 1 / ( x ^ 3 ) + 1 / ( x ^ 5 ) )
>
> and if you write it well:
>
> (with-infix
> if a = b then format t "equal ~D~%" a ;
> else format t "diff ~D /= ~D~%" a b ; endif ;
> for i = 1 to 10 ; print i ; next i )[/color]

CGOL is an Algol-like syntax for MacLisp that was designed by Vaughn
Pratt. I believe it has been ported to CL.

ABSTRACT

MACLISP programmers who feel comfortable with ALGOL-like
notation, that is, an algebraic style in which one might write a
matrix multiply routine as

for i in 1 to n do
for k in 1 to n do
(ac := 0;
for j in 1 to n do
ac := ac + a(i,j)*b(j,k);
c(i,k) := ac)

can now write LISP programs in just such a notation. This notation is
essentially transparent to the MACLISP system, and files containing
CGOL code (possibly mixed in with standard code) can be read by the
interpreter and compiled by the compiler just as though they were
written in straight LISP notation.


It has never caught on, though.

[color=blue]
> I'll tell you the secret: yes there are alot of parethesis. This is a
> price all lispers pay for greater benefits. It gives us such
> advantages that we gladly pay the price.[/color]

Excerpts from real C header files:

#define FromHex(n) (((n) >= 'A') ? ((n) + 10 - 'A') : ((n) - '0'))
#define StreamFromFOURC C(fcc) ((WORD) ((FromHex(LOBYT E(LOWORD(fcc))) << 4) + (FromHex(HIBYTE (LOWORD(fcc)))) ))
#define ToHex(n) ((BYTE) (((n) > 9) ? ((n) - 10 + 'A') : ((n) + '0')))
#define MAKEAVICKID(tcc ,stream) MAKELONG((ToHex ((stream) & 0x0f) << 8) | (ToHex(((stream ) & 0xf0) >> 4)),tcc)

#define va_arg(AP, TYPE) \
(AP = (__gnuc_va_list ) ((char *) (AP) + __va_rounded_si ze (TYPE)), \
*((TYPE *) (void *) ((char *) (AP) \
- ((sizeof (TYPE) < __va_rounded_si ze (char) \
? sizeof (TYPE) : __va_rounded_si ze (TYPE))))))

#define PLAUSIBLE_BLOCK _START_P(addr, offset) \
((*((format_wor d *) \
(((char *) (addr)) + ((offset) - (sizeof (format_word))) ))) == \
((BYTE_OFFSET_T O_OFFSET_WORD(o ffset))))

[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]
>[color=green][color=darkred]
> > > R5RS has `for-each' which is exactly like `mapc', but no `dolist'
> > > equivalent. In Scheme, this is not a problem, in Lisp, the syntax
> > > makes me worry for the extra effort in creating a closure.[/color]
> >
> > what me worry? about syntax?
> > [...][/color]
>
> You completely missed my point.[/color]

if the point was about something other than when and if a closure is created
and whether that differentiates lisp from scheme, then yes, i did.

....

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme

Tim Hochberg <tim.hochberg@i eee.org> writes:
[color=blue]
> Pascal Bourguignon wrote:[color=green]
> > Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> writes:
> >[color=darkred]
> >>On Tue, 07 Oct 2003 21:59:11 +0200, Pascal Bourguignon wrote:[/color][/color]
> [SNIP][color=green][color=darkred]
> >>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.[/color]
> > Well, I would say that kanji is badly designed, compared to
> > latin
> > alphabet. The voyels are composed with consones (with diacritical
> > marks) and consones are written following four or five groups with
> > additional diacritical marks to distinguish within the groups. It's
> > more a phonetic code than a true alphabet.[/color]
> [SNIP]
>
> Admittedly, I found the above paragraph pretty hard to parse and my
> never stellar knowledge of Japanees has mostly evaporated over time,
> but I'm pretty sure you are talking about Hiragana (or Katakana), not
> Kanji. Japaneese has three alphabets, which they mix and match in
> ordinary writing. Kanji aren't phonetic at all, they're ideograms, and
> can typically be read at least two completely different ways depending
> on the context, making reading Japanese extra confusing for the non
> fluent.[/color]

Absolutely. My mistake, sorry. I wrote about katakana and that was
not the subject.

[color=blue]
> A random web search supplies this basic descripion of Hiragana,
> Katakana and Kanji:
>
> http://www.kanjisite.com/html/wak/wak1.html
>
> -tim
>[/color]

--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

Do not adjust your mind, there is a fault in reality.

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme

prunesquallor@c omcast.net writes:[color=blue]
> Excerpts from real C header files:
>
> #define FromHex(n) (((n) >= 'A') ? ((n) + 10 - 'A') : ((n) - '0'))
> #define StreamFromFOURC C(fcc) ((WORD) ((FromHex(LOBYT E(LOWORD(fcc))) << 4) + (FromHex(HIBYTE (LOWORD(fcc)))) ))
> #define ToHex(n) ((BYTE) (((n) > 9) ? ((n) - 10 + 'A') : ((n) + '0')))
> #define MAKEAVICKID(tcc ,stream) MAKELONG((ToHex ((stream) & 0x0f) << 8) | (ToHex(((stream ) & 0xf0) >> 4)),tcc)
>
> #define va_arg(AP, TYPE) \
> (AP = (__gnuc_va_list ) ((char *) (AP) + __va_rounded_si ze (TYPE)), \
> *((TYPE *) (void *) ((char *) (AP) \
> - ((sizeof (TYPE) < __va_rounded_si ze (char) \
> ? sizeof (TYPE) : __va_rounded_si ze (TYPE))))))
>
> #define PLAUSIBLE_BLOCK _START_P(addr, offset) \
> ((*((format_wor d *) \
> (((char *) (addr)) + ((offset) - (sizeof (format_word))) ))) == \
> ((BYTE_OFFSET_T O_OFFSET_WORD(o ffset))))[/color]


:-)


However, taking sources written by the same programmer (me), at about
the same period, I get thrice or twice as many parenthesis in Lisp
than in C:

------- ----- ----- ------------------------------------
(-paren loc (/lin Language
------- ----- ----- ------------------------------------
160 / 627 = 0.255 COBOL sources.
6697 / 18968 = 0.353 C sources (.h + .c)
327 / 825 = 0.396 Java sources.
9071 / 18968 = 0.478 C sources, counting both ( and {
15 / 31 = 0.484 FORTRAN-IV (I've got only one toy program).
15224 / 29990 = 0.508 Modula-2 sources (* comments! *).
14754 / 13890 = 1.062 Lisp sources.
------- ----- ----- ------------------------------------

That's not much more...




for f in *.{h,c,lisp} ; do printf "%6d " $( sed -e 's/[^(]//g'<$f|tr -d '\012'|wc -c ) ; wc $f ; done|awk '{p=$1;l=$2;w=$ 3;c=$4;n=$5;pri ntf "%6d / %6d = %6.3f %s\n",p,l,p/l,n;pt+=p;lt+=l ;}END{printf "%6d / %6d = %6.3f %s\n",pt,lt,pt/lt,"Total";}'


--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

Do not adjust your mind, there is a fault in reality.