Re: How about this syntactic candy?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On 2007-11-24 22:52:24 -0800, "Hilton" <nospam@xxxxxxxxxx> said:

I never claimed to develop a syntax that prevented buggy code being written.

What's the point of "const" here if it's not enforced? The only thing I can think of that's worse than adding a rarely needed, rarely beneficial syntax is adding one that actually allows one to lie to the compiler in a way that _breaks_ the code.

:) Anyway, your example would not compile - you changed my suggestion. I
suggested: "for (int i = 0; i < const list.Count; i++)" and I bet the
compiler writers could add this very very simply.

What's the difference? Are you proposing that the only legal variation of the syntax would be "[comparison operator] const"? If so, then I submit that's an even more limited addition (and thus unwarranted) than I'd originally thought you were talking about.

If not, then perhaps you could be more clear about what it is exactly you're proposing. So far, you haven't been very specific.

C# and other languages are full of syntactic candy.

I never said there's never any use for it. But it should add real value, rather than being some sort of gimmick.

e.g. A ? B : C.

Well, first of all, lots of languages do okay without that. But more significantly, IMHO, the reason that syntax has survived so many generations of this family of languages is that it's so commonly useful. It _significantly_ abbreviates the code, but in a way that's still quite readable. More important, it provides a syntax to do something that would simply not be practical any other way.

The primary alternative would be to write a function to perform the test. It's not just some abbreviated way to write something the language supports via other means. It provides a way of representing an expression with a conditional value, without the overhead of having to call a function.

In C you could hack it together by taking advantage of a boolean expression evaluating to 0 or 1, but it would be significantly _less_ readable that way, and much more complicated to write. In C# it gets even worse, because you'd have to get around the languages reluctance to treat the bool type as a numerical type in the first place.

IMHO, your suggestion doesn't even come close to solving the kind of issues that an expression like "A ? B : C" solves.

What
about the foreach to loop through stuff even when it is MUCH slower than a
simple for loop.

What about it? It's true, IEnumerable is slower than the usual simple mechanisms available via an indexing for() loop. So what? For one, there's a real code-correctness and maintainability value in having a typed enumeration of some collection, and for another it would be unusual for the speed difference to have any real significance in your code.

And in those rare cases when it does, then fine...write it as an indexed for() loop instead.

But first of all, don't waste time optimizing until you have shown there's a need. Sound familiar? And secondly, what's foreach() got to do with this thread? If you're using foreach(), you're not going to be able to use "const" as you suggest anyway.

My suggestion speeds things up 2x (see my other post),

It speeds things up 2x in a very specific test, and a degenerate one at that. I doubt it would have anywhere close to that kind of difference in code that actually did something interesting.

is easy to read,

That's definitely an "eye of the beholder" thing.

and adds no new keywords.

It does add a new interpretation of an existing keyword, and especially in the context of C# it's a fairly orthogonal interpretation at that ("const" not having all of the same uses in C# that it has in C++).

For the record, I know the exact
same thing can be done with a temporary variable, but IMHO, "const" is much
easier to read.

Again, "eye of the beholder". I find that it obscures a key detail with respect to the implementation, one that's obvious and hard-coded rather than assumed when a local variable is used.

In any case, when you write code that copies a value to a local, you are _guaranteeing_ the compiler that the value won't change. No such guarantee is made if you insert "const" in the condition for the loop, and that's a definite code-correctness problem.

I will pick maintainable and correct code over fast every single time. YMMV.

Pete

.

Relevant Pages

  • Re: Fridays the thirteenth. (And a little puzzle.)
    ... -- compiler) is the usual method ... int febdays ... -- We're going to go round a loop dealing with each year in turn. ... -- other languages call) ...
    (uk.people.silversurfers)
  • Re: more idle thinking: SiMPL
    ... I am thinking of an odd piece of syntax: ... by extension: ... treatment of ';' could be a little more flexible than in C family languages, ... likely make an unreasonable headache for the compiler (AKA: ...
    (comp.lang.misc)
  • Re: strlen(), K+1: clarification
    ... you can't optimise strlenand move its evaluation out of the loop ... You are correct that you cannot move strlen out of the loop ... however that has nothing to do with the compiler not knowing ... All languages have ...
    (comp.programming)
  • Re: ANN: pldev.org
    ... As for left$ and right$, I actually prefer that syntax ) ... languages can vary and it's probably not good to depend on specific ... with value b+1, or b-1 if using 'downto', if the loop terminates normally. ... especially if the compiler is clever enough to detect when it might change; ...
    (comp.lang.misc)
  • Re: Integer arithmetic
    ... for Index in Container'Range loop ... In that case, the compiler will know that Index is in range, as in any language. ... This also lets Index be a ordinary int, which stops you getting tied up in ... /2 in my syntax), when the bounds of such structures are so strictly typed? ...
    (comp.lang.misc)