C's syntax (was Re: Python Formatted C Converter (PfCC))

[William Tanksley]

On Thu, 26 Oct 2000 22:04:17 +0100, Grant Griffin wrote:
>William Tanksley wrote:

>> The pitfalls, for one ;-).  C also makes pointers look terrible.

>Yeah, I greatly appreciate reference parameters that C++ supplies for
>passing stuff into and out of functions.  If there were such as thing as
>"C+", that would be one of its features.

Interesting point.  I don't care one way or the ather about references; I
usually prefer to work with pointers.  I was talking more about things
like the distinction between -> and . (why? there's never any semantic
confusion), or the way pointers are declared (which works, but seems
really stretched once you start typedefing or looking at C++).

And just in general use, it's odd that pointers have to be treated as such
advanced concepts in C, when they're such a basic part of so many other
languages.

>That being said, I think Python's paradigm of (being able to) return a
>"list" (actually a "tuple") is a much better way to pass things out of
>functions.  The fact that a C function can pass 0 or 1 return items is
>very artificial: we routinely defeat that using pointer arguments or
>references when we need to "return" multiple values.

Absolutely.  S-Lang did a very good job of that as well (by providing
access to the stack itself inside of a C-style syntax).

>> Ugh.  I HATE the C preprocessor.  Wouldn't it be beautiful to be able to
>> parse the language using the language's own capabilities?  Or at least to
>> be able to have some limited parsing and computation at compile-time?

>I can see the value of that, to an extent.  But I really like the "dumb
>substitution" that "#define" does.  I've worked with assemblers and
>other tools where they had dopey restrictions on what you could and
>couldn't substitute.  In a way, I think the text-substitution paradigm
>is powerful in many ways for the fact that it _doesn't_ understand the
>code!

I wasn't saying that the substitution should be able to understand what it
is that it's substituting -- I was only pointing out that it should be
_able_ to parse it.

This becomes especially silly with C99's vararg macros, but anyone who's
ever tried to compute a #defined value will appreciate the problem.

>> Once you play with Forth, you're pretty much ruined for any other
>> language...  Even Lisp just doesn't cut it.

>So why are you here? <wink>

I'm being unfaithful.  Shh, Forth doesn't know.

Python doesn't even try to be able to process its own macros.  It does
this by the surprisingly economical method of not having any macros at
all.  Therefore, it can't compete against Forth ;-).

>I have friend who has tried hard to sell me Forth, and I've been trying
>hard to sell him Python.  (What should I tell him?)

Oof.  That's a tough one.  Not because Python sucks compared to Forth, but
rather because switching languages is rare.

There are a lot of areas where I'd use Python but not Forth.  Some of
those areas are simply there because I'm more familiar with the Python
style of programming, thanks to years of training on Python-style
languages (C, Pascal, Lisp, etc.); others are there because Forth doesn't
detect errors or have automatic memory management.

Of course, there's now a strongly staticly typed Forth, so I might still
disappear.  I've never seen such a simple but powerful typechecking/static
polymorphism system.

>evangelistic-ly y'rs,
>Grant R. Griffin                                       g2 at dspguru.com

-- 
-William "Billy" Tanksley