🚀 go-pugleaf

In article <65696@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> From article <10635:Oct1213:40:5990@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> ] In article <65409@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> ]> Why indeed?  Why force the programmer to use explicit pointers when
> ]> the language can be designed to allow the programmer to explicitly
> ]> state what he really wants to do?
> ] That's another really stupid statement. Jim, if I take your favorite
> ] language and add pointers to it without telling the programmer, HOW WILL
> ] HE EVER KNOW? How will adding pointers *force* him to stop using your
> ] gaggle of data structures? How? How? How?
> Well, if this were an argument over what should be _added_ to a
> language after all the features I desire were already present, then
> your point would be quite valid.

What the hell are you talking about? You made a stupid statement. I
asked you questions designed to show its stupidity. Now you're failing
to answer the questions. Predictable, I suppose.

You're repeatedly making statements like these:

  Pointers can never be more efficient than arrays because *(p+i) is
  just as slow as p[i].

  Pointers inherently force the programmer not to use any higher-level
  abstraction.

  All data structures may be expressed as recursive data structures.

You refuse to acknowledge that sometimes pointers can be used without
adding an index first, that some of us don't mind using the most
appropriate available tool for the job, and that packed array tries
cannot be expressed as recursive data structures. Hell, you refuse to
even look up packed array tries so that you know what you're talking
about.

> But, this _isn't_ a discussion over what to put into a language in
> _addition_ to the features I recommend!  Every time I recommend (for
> example) that a language should support arrays, the C supporters
> immediately claim that I don't need them since pointers already
> give me all the functionality I need.

Oh? C'mon, Jim, you're modifying history here. Maybe some C fanatics
have religious objections to your language. I don't, and I don't know
anyone who does. What I see happening is you suddenly shouting
``Pointers are evil! Pointers are useless!'' in the middle of what had
previously been perfectly reasonable discussions.

> ]> It's easier for the programmer,
> ] No! If I take C and add the Giles Gaggle to it---through macros, a smart
> ] preprocessor like C++, or whatever---is the programmer ``stuck'' with
> ] pointers? No!  [...]
> Well, actually in this case the programmer _is_ still stuck with
> pointers.
  [ various red herrings ]

Jim, nothing in Nemesis that you've described to me requires any
extensions to implement in C; you haven't told me about the syntax, but
that doesn't really matter. The programmer can get all the greatness and
glory of the Giles Gaggle, with whatever typechecking and constraints
you want, with at most a C++-like preprocessor. Agreed?

  [ efficiency concerns, including: ]
> And how does a macro or other preprocessor even
> _begin_ to tell the compiler about no-alias conditions?

Aha! You finally bring up an issue worthy of discussion!

For the compiler to take advantage of un-aliased variables, it either
has to compile several copies of the code with different aliasing
restrictions, or let the programmer talk about aliasing somehow. Convex
lets you selectively specify pointer arguments as unaliased, for
example. Q has an assertion to express the lack of aliasing. I admit
that C as is, while powerful enough to support the Giles Gaggle, may not
be perfectly efficient without some extensions. This is an area where
language design has to advance.

> ] STOP SAYING THAT POINTERS MAKE THINGS HARDER FOR THE PROGRAMMER!
> Ah, but they _DO_ make programming harder if they are the _only_ means
> of support for the features we've been discussing.  It has been _your_
> contention until this very article that pointers _should_ be the only
> means of support for these features.

Either you're mistaken or you're lying. I expect an apology.

> ] If you're trying to say that high-level data structures make things
> ] easier, SAY IT! STOP MAKING FALSE, RIDICULOUSLY MISLEADING STATEMENTS!
> What?  Am _I_ the one who claimed that recursive data structures could
> never be used for 'trie' data structures?  Am _I_ the one who claimed
> that only the pointer data type would allow reversing a stack by swap-
> ping links?

I did not make either of those statements. I expect an apology.

Recursive data structures can never be used for packed array tries.

Recursive data structures do not allow bounded-memory reverse-direction
traversal of, say, a stack or tree.

> And, I _HAVE_ been saying that high-level data structures make things
> easier - a _LOT_ easier than the "pointers only" approach.

No. You've been spending your time saying how bad pointers are.

> ]> easier for the compiler to generate efficient code,
> ] Now *that* is a reasonable assertion. It doesn't make you look like an
> ] idiot, it's a good basis for discussion, and it fact it's the *only*
> ] thing that could be considered a ``pointer problem.'' Any arguments for
> ] eliminating pointers must be based *solely* on compiler and run-time
> ] efficiency.
> In addition, arguments about _any_ language feature should include as
> much information about human factors as possible.  You are trying to
> exclude this.

No; I merely see that this is not a human factor issue.

> But, at least in my experience, pointers are associated
> with more than their fair share of hard to find errors.

Fine. If you believe this based on your experience with C, provide
something better. However, this isn't relevant to the issue of whether
pointers belong in a language, which is what we are discussing. (You
brought it up in the first place.)

---Dan