Re: Simple question, err... I think



* "Dr" Jon Harrop:
Alf P. Steinbach wrote:
Here, I must side with Alf, but only because Jon went out on an
unnecessary limb at this point. The pattern-matching code is /not/
what most programmers would call "readable."
However, this should not detract from the main point, which was
to provide Logan with an illustration of pattern-matching code that
is /more readable than the equivalent C++ code/. In that, the above
code succeeds (though perhaps not admirably ;).
No, the example doesn't show anything.

Given that other people have understood the example, I think this means that
you haven't.

Putting aside, for the moment, the question of who these people you refer to could be, is your definition of "understood" that they agree with your conclusions? If not, how can you be sure they have really understood your example? And if they do agree with you (assuming they exist, of course), isn't it then the case that in your view only those who agree with you, understand your examples, and the others, not?


Even ignoring the complete lack of readability this is ungood C++
Can you provide C++ that you prefer?
Still ignoring the aspect of readability, you can check out the
implemention of std::map::insert (standard library code is optimized
for fast compilation, not for readability, but it's otherwise good).
I may be missing something, but how is std::map::insert relevant?
The poster I responded to asked for example code for C++ red-black tree
insertion: std::map::insert is in practice such code, freely available.

You're welcome to look at map::insert. From the point of view of this
argument, it is the same.

No, I welcomed you to look at it, at your request for C++ code.

It's meaningless to then direct me to look at the code.

Btw., which implementation did you look at?


Nitpick. Jon's memory management was all encapsulated in "alloc()".
Whether "alloc()" is implemented with malloc, or new, or some crazy
homegrown mechanism, that doesn't affect the example one whit. The
only substantive difference here is that the FP example was
garbage-collected, and C++ isn't.
The above is also meaningless to me. It's not true that the R() and B()
functions in Jon's code (I assume those are what you mean by 'alloc()',
which is nowhere to be seen) constituted memory management. Furthermore
it's not true that C++ is necessarily not garbage collected, but if
garbage collection was assumed it should have been mentioned, since it's
not required by the standard.

You're evading the question: what would you prefer?

I'm not aware that that question has been asked, and I'm baffled as to what it could refer to. I'd prefer, well, two things, right now, but would you, I wonder? That's just as on-topic and just as much reflecting internal thought processes, which can only be revealed by means of telepathy, as your indecipherable combined challenge+question.


* exception unsafe.
It uses exceptions.
To apparently leak memory, yes.
Memory leaks simplify code. :) Seriously. Trying to catch every
leak in the C++ code would presumably have made the code longer and
more complicated, not shorter. So that's a point for the FP side,
and totally irrelevant to pattern-matching, which was the point of
the example.
If the code doesn't need to be correct it can be anything. It's highly
relevant.

Where is the memory leak?

Darn, you're asking a technical question, not just rhetoric. I wrote /apparent/ memory leak, but it doesn't matter whether there really is one, because the code is incorrect anyway (given the extremely low quality of the code it felt safe to assume a leak :-)). It starts:

typedef Node * Set;
Set E=0;
Set R(Set l, int n, Set r) { return new Node(true, l, n, r); }
Set B(Set l, int n, Set r) { return new Node(false, l, n, r); }

struct Found { Found() {} };
Set ins(const int x, Set p) {
if (!p) return R(E, x, E);
const int y = p->n;
if (p->is_red) {
if (x < y) {
Set l2=ins(x, p->l);
if (l2 == p->l) throw Found();
delete p->l;
return R(l2, y, p->r);
}

/All/ 'return' statements in this function return a pointer to a freshly allocated node, using either R or B, which do not update the existing data structure. In the code above, l2, obtained this way, is then compared to an existing pointer, p->l. For a valid pointer value p->l this comparision will always yield false, which is the first glaring error in this code snippet. Second, delete p->l is executed without reassigning that member, which results in an invalid pointer value in the structure, which is the second glaring error in this code snippet.

It might be that the two errors mentioned do not affect the final result, e.g., that this function is always called with p == 0.

But that does not matter.


* nonstandard exception.
What exception would you prefer?
Standard exceptions (in general, derive from std::runtime_error, and
don't use exceptions to break out of successful recursion).
Nitpick.
No, again, to compare examples expressed in different languages, they
must as a minimum be representative of the languages.

Subjective.

Nope, it shows that the author of the examples doesn't know the language well, so the example is not anything to go by.


I confess I don't know what's going on with that "throw
Found()" in the second snippet, but again, I can only assume that it's
easier to throw an exception than to properly wind up the stack at
that point. Which results in shorter C++ code, not longer.
No, that isn't necessarily so.

The Found exception is thrown when the given element is found to be already
in the set.

Well, duh, you probably meant to return a pointer to the node where it was found (hence the always-false comparision, which could then be meaningful).


Your C++ example is not an example of natural coding in C++, and I
doubt
the other examples are natural.
Your objection is entirely subjective.
Not at all.
Yes, entirely subjective.
No, not at all: only objective criteria have been listed.

Nonsense: "Natural" is not an objective criterion. And it is your only
criterion. Moreover, you still haven't provided more "natural" code.

Let's first analyse this code to death. ;-)

Then, when it's good and dead, we can discuss why on Earth I should provide you with a working solution.

Are you sure this isn't homework?


[snip]
Which is another subjective criterion. Objectively, they both do the same
thing.

If you mean, in the sense of being incorrect, yeah perhaps. But there is a chance the pattern matching code is correct. I don't know the language.


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
.