IfThen function

[Чебурашка]

or macros like the one I wrote above.

As I've already pointed out, FPC's macros don't take parameters. Your example in #6 won't work.

MarkMLl

Of course, I was referring to C marcos.

[Paolo]

Uhm.... I did not catch this ifthen implication.
If then esle construct is to select the right branch under boolean condition skipping the other branch, what is the purpose of ifthen if both branches are computed ?

[Чебурашка]

Uhm.... I did not catch this ifthen implication.
If then esle construct is to select the right branch under boolean condition skipping the other branch, what is the purpose of ifthen if both branches are computed ?

Also free pascal IfThen() function is often very useful, for example:

Code: Pascal  [Select][+][-]

1. Color := IfThen(condition, clGreen, clRed);
2.  

Of course if one wants to skip evaluation of unused branch, IfThen is not the solution and if then else must be used unless new constructs are added.

[Zoran]

PascalDragon once gave me some hope that the if-then-else (be it a function intrinsic or some kind of a ternary operator, whatever) construct will get into language eventually...

[Чебурашка]

PascalDragon once gave me some hope that the if-then-else (be it a function intrinsic or some kind of a ternary operator, whatever) construct will get into language eventually...

In PascalDragon we trust.

[MarkMLl]

PascalDragon once gave me some hope that the if-then-else (be it a function intrinsic or some kind of a ternary operator, whatever) construct will get into language eventually...

In PascalDragon we trust.

I did take the trouble to link to his posting and the unapplied patches in my first response.

MarkMLl

[Zoran]

PascalDragon once gave me some hope that the if-then-else (be it a function intrinsic or some kind of a ternary operator, whatever) construct will get into language eventually...

In PascalDragon we trust.

I did take the trouble to link to his posting and the unapplied patches in my first response.

MarkMLl

I know, Mark, I didn't miss your post.
I just wanted to say that, although his work didn't make it in the language at the time, we might get this feature after all (in some different form perhaps).

[PascalDragon]

Apropos Concat(), I admit to almost always using its equivalent + operator. However as Pascal gains more overloading and dynamic array capabilities I'd be far happier if something like a _ operator were defined to (also) mean concatenation, so that it was possible to override + meaning "add these arrays" and _ meaning "concatenate these arrays". But I know that's not going to happen.

_ is already used in main as digit separator. Best not to confuse that as an operator as well...

[MarkMLl]

_ is already used in main as digit separator. Best not to confuse that as an operator as well...

Plus it's valid in an identifier. The only realistic way something like that would work- in just about any language- would be if there were mandatory whitespace on both sides. And that ain't going to happen.

Hmm. How about ^ in a string or array context as concatenation, even if it's not overridable?

MarkMLl

[PascalDragon]

Hmm. How about ^ in a string or array context as concatenation, even if it's not overridable?

So you never dereference a PString or a pointer to a static array?

[MarkMLl]

So you never dereference a PString or a pointer to a static array?

Please correct me if I'm wrong, but I didn't think there was a mode in which a Pstring or ordinary pointer was automatically dereferenced. So postfix ^ (applied to a pointer) and infix ^ (applied to two strings) are distinct.

And I know from discussion with Jonas years ago that ^ is unlikely to be added to the list of operators which can be overridden.

MarkMLl

[PascalDragon]

So you never dereference a PString or a pointer to a static array?

Please correct me if I'm wrong, but I didn't think there was a mode in which a Pstring or ordinary pointer was automatically dereferenced. So postfix ^ (applied to a pointer) and infix ^ (applied to two strings) are distinct.

I'm not talking about automatic dereferentiation: Does SomePString^^SomeString really read so much better than SomePString^+SomeString (and yes, I left any spaces out on purpose)?

And I know from discussion with Jonas years ago that ^ is unlikely to be added to the list of operators which can be overridden.

That doesn't make the ^ a better choice for something like this.

[MarkMLl]

I'm not talking about automatic dereferentiation: Does SomePString^^SomeString really read so much better than SomePString^+SomeString (and yes, I left any spaces out on purpose)?

But the issue is not replacing + as concatenation, it's decoupling + from concatenation so that it could potentially be used for summing (the content of) dynamic arrays.

That doesn't make the ^ a better choice for something like this.

What's the alternative? Just about everything else is either already used in the syntax, or will be swallowed by the lexer, or will introduce internationalisation issues because it's not in 7-bit ASCII.

The issue is this:

When the ArrayOperators modeswitch is in effect:
{$modeSwitch ArrayOperators}

then the + operator cannot be overloaded on dynamic arrays, because it is handled internally by the compiler.

which is currently at 15.2 of the reference manual: it would- IMO- be highly desirable to remove that so that addition of arrays could be overloaded, while still having a shortcut for concatenation of arrays and strings... and it would be reasonable IMO for that shortcut to not be overloadable since it is basically syntactic sugar.

MarkMLl

[dseligo]

What's the alternative? Just about everything else is either already used in the syntax, or will be swallowed by the lexer, or will introduce internationalisation issues because it's not in 7-bit ASCII.

! ? | \ ~ "

And some character pair could probably also be made.

[MarkMLl]

What's the alternative? Just about everything else is either already used in the syntax, or will be swallowed by the lexer, or will introduce internationalisation issues because it's not in 7-bit ASCII.

! ? | \ ~ "

And some character pair could probably also be made.

I was wondering about ~ but was wary since some "regional ASCIIs" might omit it. If safe, it would be the obvious contender since I don't think the C family uses it as an infix operator so nobody could argue that it would break expected idioms.

MarkMLl