Hi,

I like when Free Pascal trying to implement best practices from other languages. That was with increment variable using assign operator: i += 1. Anyway, few days ago I analyzed C++ code and I liked one syntax:

if ( ( i = GetSomeValue ) >= 10 ) {

  // variable "i" already has value returned by GetSomeValue

}

I wonder if FPC has equivalent for this.

Regards

I hope not.

Why do you use Pascal if you want this ugly C-crap-style? Even the i += 1 is a sin.

*shudder*
Michael

No, and thanks Wirth for that, and for FPC/Delphi devs for not adding it up. It's one of the worst possible features ever existed in programming languages, and the cause for many bugs

Even C has some equivalent:

i = GetSomeValue;
if ( i >= 10 ) {
  // no comment needed, the value of i is obvious
}

Mattias

I don't like a lot of C++ syntax but this one is interesting. You really don't like it? :)

In our previous episode, Krzysztof said:

I don't like a lot of C++ syntax but this one is interesting. You really don't like it? :)

It's the worst thing ever. 95% of the hard to find errors in C in my code are due to = vs == mixup.

C programmers are (usually, but there are a lot of exceptions) bad programmers who confuse the power of a language with the capability of decrease the ammount of typing needed to reach a certain goal.

They despise pascal because pascal is somewhat verbose (ignoring that this is what makes pascal readable) because they think that the best language is the one wich allows to write a whole program in a single line of code.

Thats because they dont usually think before writing, they think while they are implementing, and then the only thing between current momment and the momment when their program is "ready" is the ammount of typing.

Pascal programmers tend to plan ahead, they think before they type. We type a lot because of Pascal verboseness, but usually our code is right from the start. We end up typing less because we fix less bugs.

Pascal generally improves programmer productivity. Lets not break this by adding crazy ideas from C/C++ family of languages...

2013/1/8 Marco van de Voort :

I don't like a lot of C++ syntax but this one is interesting. You really

don't like it? :)

HELL NO! Most C/C++ programmers don't have any idea who will READ and CONTINUE their work, and I'm one of those unlucky person who has to deal with this stupid, error prone, unreadable, worthless "feature"!

Seconded. In fact, if assignment didn't propagate a value like that I'm not sure a distinction would have to be made between (C-style) = and == or (Pascal-style) := and =

Krzysztof wrote

I don't like a lot of C++ syntax but this one is interesting. You really don't like it? :)

Most C programmers I've dealt with (including myself) consider this bad practise.

Henry

"Better to keep your mouth closed and be thought a fool than to open it and remove all doubt"

Your phrase almost made me care about...

Do you wanna make me care ? Show some points, make a constructive critic about what i said etc.

For all that matter, your answer is just a plain old argumentum ad hominem, a fallacy category, and being a fallacy, tells me you cant really make a good answer, so i infer you are the idiot here.

2013/1/8 Henry Vermaak :

Jorge Aldo G. de F. Junior wrote

Your phrase almost made me care about...

And that's enough for this little language war, thank you. Feature requests like this can certainly be discussed, but please do so without starting to insult programmers using other languages or each other.

Thanks,

Jonas
FPC mailing lists admin

Please- that really wasn't called for. It's quite obvious from context that Henry was simply agreeing with your

But if you want an example of a very nasty bug caused by C/C++ multiple assignment, there was a well-documented attempt to slip a privilege escalation into the Linux kernel based on this a few years ago.

It's very easy to argue against multiple assignment. It's less easy to argue against implementing an equivalent of the C/C++ conditional.

Are you talking about this one?

http://lwn.net/Articles/57135/

Henry

Yes, although it took me a few minutes Googling after I posted the earlier comment before I had the reference to hand.

I've got a vague recollection that since that episode the kernel maintainers have mandated a use of parentheses that helps the compiler pick up the distinction between an equality and an assignment. But it's unfortunate when programmers have to use a contrived form to work around sloppiness in the language design... I'm specifically talking about ill-conceived syntax here, not about flexibility that you get from easy access to things like pointer arithmetic.

Mark Morgan Lloyd wrote

I've got a vague recollection that since that episode the kernel maintainers have mandated a use of parentheses that helps the compiler pick up the distinction between an equality and an

Assignment inside if statements are usually frowned upon in the kernel. gcc warns if you don't use parentheses, but I usually use parentheses for readability, so there's always a danger of making a typo and not getting a warning. Can't remember the last time I've had a bug of this sort, but that's probably because I'm extra vigilant with conditionals. I think the decision to keep this syntax out of pascal is a good one.

Henry

I use C the words of one of the M2 vendors "We come to bury C, sir, not to praise it".

If Pascal /had/ to have some sort of multiple assignment, I'd have thought borrowing an idea from Perl and doing something like

[a, b, c] := (d = e);

would have been minimally acceptable.

In our previous episode, Mark Morgan Lloyd said:

[a, b, c] := (d = e); would have been minimally acceptable.

Did you really mean that or did you mean

 [a, b, c] := (d := e);

? :-)

:-) I meant what I wrote: a comparison on the right producing a Boolean which is assigned to three variables in a list. The parentheses were to try to make it a bit clearer, and I note that a Perl list is in parentheses rather than brackets.

I'm not saying I like it, or that it's Pascal. But something like that would probably upset the fewest people that matter. Perhaps I should have said

[a, b, c] += Ord(d = e);

:-)

In our previous episode, Mark Morgan Lloyd said:

I guess that is the bright side of it all. Sooner or later we can have an obfuscated Pascal contest, just like the other ones :-)

Marco van de Voort wrote

I guess that is the bright side of it all. Sooner or later we can have an obfuscated Pascal contest, just like the other ones :-)

I'm sure we can already have a contest just with the careful application of macros :)

Henry

If Pascal /had/ to have some sort of multiple assignment, I'd have

thought borrowing an idea from Perl and doing something like

[a, b, c] := (d = e);

would have been minimally acceptable.

I would pick from Lua instead, it looks cleaner. Well... I'll make it stricter though, by making the number of elements on both side must equal. e.g.:

a,b,c := v1,v2,v3;
a,b := b,a; // value swapping

I admit that I was- in large part- borrowing from APL. In other words, if the number of elements on both sides of the expression is the same you get a one-to-one correspondence but if the RHS only has a single element it's expanded. APL will also do things comparable with treating

[a, b, c, a] := [1, 2];

as though it really was

[a, b, c, a] := [1, 2, 1, 2];

but that's getting well outside what's reasonable particularly since APL makes a point of not defining the order of internal operations (i.e. the final value of a is, at best, implementation-defined).

However as I said: it's not Pascal :-)

In other words, if the number of elements on both sides of the expression

is the same you get a one-to-one correspondence but if the RHS only has a single element it's expanded.

That's what I want to avoid because I love Pascal strictness :)