Hello together!

The IfThen() intrinsic has been removed again. There will be *no* replacement in the foreseeable future. This is not up for discussion.

Regards,
Sven

luddite_clique 1 progressives 0

John Lee wrote

luddite_clique 1 progressives 0

Please don't start a flame war.

Bart

John Lee wrote

luddite_clique 1 progressives 0 Just wait for Delphi to implement this... speaking of which, why they've

not done it a long time ago?
They could, but probably didn't do that, for very likely the same reasons.

thanks,
Dmitry

Disappointed :(

Why was it done? I thought that pretty much everyone was in favor?

It isn't very pascalish, that's true, but we could implement it like the proposed "inline if A then B else C" syntax... which is very pascalish and cool.

thanks,

2016-02-04 18:41 GMT-02:00 Felipe Monteiro de Carvalho <

Due to the fact that we like flame, flame and flame

Lets wait for the Delphi implementation so, we will not start a new flame.

The same applies to the ARC objects.

Best regards

Mazola Winstrol wrote

Lets wait for the Delphi implementation so, we will not start a new flame.

You mean like "wait 5-10 years until they decide independently that they want to do it" or are there serious plans for Delphi to support this, say, in the next version?

The same applies to the ARC objects.

What's that?

2016-02-04 19:13 GMT-02:00 Felipe Monteiro de Carvalho <

features do not exists in Delphi. We prefer flame.

Reference-counted objects. Class instances are counted by reference so, this feature eliminates the need to manually manage memory with the try...finally blocks to free objects from the memory.

Best regards

Hi,
I personally think that there's no place for democracy in compiler development. It would lead to bloat. Although majority of people considered it useful, it was not very pascalish. Trunk is place for experiments and this one is over.  
V.
______________________________________________________________

Hello together!

The IfThen() intrinsic has been removed again. There will be *no* replacement in the foreseeable future. This is not up for discussion.

Regards,
Sven

Felipe Monteiro de Carvalho wrote

Disappointed :(

Well, such is life.
I'm also disappointed that my bank account doesn't contain millions. But I learned to live with it :-)

But all hope is not lost yet.

Why was it done? I thought that pretty much everyone was in favor?

Not quite, form was also deemed important. It is a tricky balance.

To recapitulate:

There were various choices:

a) not adding at all
b) a ? b : c
c) if a then b else c
d) iif() (or some variant thereof)

From the people that responded in the core discussion, the majority was for the

a ? b : c
syntax, or not adding at all (not all replied).

Now, the functional form (ifthen(), iif() or whatever) is not consistent with the semantics of other functions, namely that all arguments are evaluated. Opinions on the importance of this argument may vary, but it must not be ignored.

Since the functional form (IfThen) violates above rule, it was removed again.

Sven did not feel like introducing the a ? b : c syntax, so it was not added.

If someone feels like submitting a patch that implements a ? b : c, it may well be taken under advisement. I heard no-one speaking out clearly against the actual functionality (well, maybe one) or the a ? b : c form.

Sven simply didn't want to implement the a ? b : c form.

This should be respected, each works on what (s)he wants to work. That is not to say that all work done is automatically and irrevocably added to the compiler.

Experiments can be done, but can also be discarded.

It isn't very pascalish, that's true, but we could implement it like the proposed "inline if A then B else C" syntax... which is very pascalish and cool.

'Cool' is a very personal appreciation.
Some men like blondes, others prefer redheads or brunettes.

For example, I don't think this is pascalish or cool.

Rationale for protest (there may have been other reasons beside the below):

"if then" is a statement. This is a clear and unambiguous rule.

Allowing "if then" as part of an expression is introducing ambiguity and error prone.

Samples of non-desirable constructs include:

Type
   TMyArray = Array[1..if sizeof(integer)=2 then 4 else 5] of integer;
   myconst = if sizeof(integer)=2 then 4 else 5;
   Procedure Something(AA : Integer = if sizeof(integer)=2 then 4 else 5);
   Property A : Integer Index if sizeof(integer)=2 then 4 else 5 read geta;
   Property B : Integer Read FA Write FA default if sizeof(integer)=2 then 4 else 5 ;

And - in my eyes - the topper in horror:

   if if if a then b else c then e else g then
      DoSomething
   else if if h then i else j then
      DoSomethingElse;

The last construct works more or less in C-like languages, because they mostly require brackets in the if(), clearly separating the if from the conditional :

if (a?b:c?e:g) {
} if (h?i:j) {
}

(whether or not one actually wants to use/read this even in C is another matter)

Then, let me point out also that the gain of this construct in terms of functionality may well be marginal.

Introducing the following generic function:

Generic function IIF<t>(Const Cond: Boolean; Const ATrueValue,AFalseValue : T) : t; inline;

(name and exact declaration may well differ, and Sven still needs to fix some inline bug)

Will solve most likely most of the use cases. I am not really a fan of generics, but the above demonstrates its power clearly.

The only use case that would be gained is the non-evaluation of one of the arguments.

To introduce a highly controversial construct for maybe marginal gain is not advisable.

That about sums up what was said about this in core.

As you see, it is not necessarily permanently off the drawing board, but has definitely been put in the (deep) freezer.

Michael.

[...]

:-D

[...]

That about sums up what was said about this in core.

Thanks a lot for all explanations.

Michael Van Canneyt wrote

b) a ? b : c From the people that responded in the core discussion, the majority was for the a ? b : c syntax, or not adding at all (not all replied).

You mean like literally using "?" and ":" ?

If someone feels like submitting a patch that implements a ? b : c, it may well be taken under advisement. I heard no-one speaking out clearly against the actual functionality (well, maybe one) or the a ? b : c form.

aha, I see, Sven's message wasn't clear about it, it sounded like core is completely against any implementation.

While actually simply no-one is working on the desired solution, which are 2 very different things.

"if then" is a statement. This is a clear and unambiguous rule.

The idea was "inline if" not "if"

Yes. As used in C-like languages.

Quoting Sven:

"There will be *no* replacement in the foreseeable future."

So

"Foreseeable future" "eternity" ? "may be implemented" : "will never be implemented"

While actually simply no-one is working on the desired solution, which are 2 very different things.

Provided you know what the 'desired solution' is, yes.

> "if then" is a statement. This is a clear and unambiguous rule. The idea was "inline if" not "if"

I don't think you are right there, but it doesn't make a difference either way.

Whether or not 'if' is preceded by 'inline' is irrelevant.

'if then else' says 'statement', not 'expression'.

'?' clearly says 'operator' hence, 'expression'.

Michael.

Michael Van Canneyt wrote

Samples of non-desirable constructs include:

Thanks goodness. Looking at some of your examples, that is a whole new can of worms, and far from what I think the Pascal language stands for.

Regards,
- Graeme -

Michael Van Canneyt wrote

I'm also disappointed that my bank account doesn't contain millions. But I learned to live with it :-)

Ah, you give up too soon. ;-)

Regards,
- Graeme -

You're more than welcome to donate. Shall I give you my IBAN ? Can't promise it's tax-deductible, though :-)

Michael.

There was also voices for a more verbose solution.

But introducing 2 new operators based on words (a-z, not 16 bit) means 2 new keywords and causes conflicts.
Except if "then" and "else" are used (but without "if") x := 1 < 3 then 5 else 4;

Michael Van Canneyt wrote

You're more than welcome to donate. Shall I give you my IBAN ? Can't promise it's tax-deductible, though :-)

:-D

G.

new keywords and causes conflicts.

Except if "then" and "else" are used (but without "if") x := 1 < 3 then 5 else 4;

No. Think about the ambiguities that arise if you use this inside the condition of an if-statement.

Regards,
Sven

What if it required use of braces:

x := (expression then truevalue else falsevalue);

?

Regards, Sven

el es

Michael Van Canneyt wrote

The only use case that would be gained is the non-evaluation of one of the arguments.

Yes, and that's pretty much the only use that I could think of, but it would be very convenient when testing for a variable to be assigned and give a default value it if is not.

Something along those lines:
http://docs.elementscompiler.com/Oxygene/Expressions/MemberAccess/

I'm not saying it should be implemented right now, but it might be a start for some thinking.

Hi,

what of
e) some kind of assignment, requiring use of braces, e.g.

   x :=  ( if condition then truevalue else flasevalue );

or

   x :=  ( condition then truevalue else falsevalue );

... ?

It also does not clash with function names, only reuses same keywords...

From the people that responded in the core discussion, the majority was for the a ? b : c syntax, or not adding at all (not all replied).

[...]

> It isn't very pascalish, that's true, but we could implement it like > the proposed "inline if A then B else C" syntax... which is very > pascalish and cool.

So might be the 'assignment', no?

I believe the assignment form would get rid of the above... because one can't use an := assignment in a declaration right?

and convert this into
x := (((a then b else c) then e else g) then DoSomething else DoSomethingElse); (

....well actually looking at this abuse it doesn't seem to be likely to work ...? unless someone does

x := (y := ( z := (a then b else c) then e else g ) then DoSomething else DoSomethingElse);

so the immediate y,z variables have to be declared. (and also requires a,b,c,e,g be boolean)

but quoting "everything can (and will) be abused" duh ;)

[...]

Just my PLN 0.02.

el es

Let's make it simple:

The use of "if", "then" and "else" are not up for discussion.

Michael.

Ah ok.

so I think no /current/ keywords would be allowed either... I see.

What of

x := ( condition, true:=truevalue, false:=falsevalue);

?

Michael.

el es

An as reusing keywords is a no-no...

I wrote x := ( condition, true := truevalue, false:=falsevalue); in previous email;
but since true and false are constants (and reserved names) too,

maybe, actually, a new keyword (pair) would be actually OK ?

x := (condition; whentrue:=truevalue; whenfalse:=falsevalue); ?

yes requiring use of assignment, braces, and assignments inside braces.

[...]

el es

el es

Anything that spells 'statement' is indeed going to meet with fierce resistance.

What of x := ( condition, true:=truevalue, false:=falsevalue);

Apart from any parsing difficulties this may present, what is the benefit over

   x:=condition ? truevalue : falsevalue

The latter being the generally used one ?

Michael.

In our previous episode, Lukasz Sokol said:

What of x := ( condition, true:=truevalue, false:=falsevalue);

Clashes too much with _() from dxgettext.

contain millions. But I learned to live with it :-)

previous email;

You're butchering the language even more than if-then-else could have -.-

Regards,
Sven

Michael Van Canneyt wrote

[...]

That it's C, not Pascal ;) and, um. sorry I do not have a c spec on hand, does it really work that way in C - only evaluates truevalue or falsevalue not both?

I wrote another one in another email, maybe actually having new keyword or 2 is ok ? and require it to be an assignment, like

x := ( condition; whentrue:=true_value; whenfalse:=false_value);

so syntactic sugar but not abusing function calls, but an assignment instead.

Michael.

el es

Uh, ok.
then what about double braces (( and )) ? Oh and using ';' for condition and values separation, not ',' like above...?

el es

I don't know about C (don't know if it actually has it?), but definitely in C++ and JavaScript

And please remember, we do not NEED this construct; the added value is marginal as I indicated.

Simply not adding is an option. Not all change is necessarily progress.

Michael.

I would have voted for if-then-else (in braces, of course) but Michael says no and I respect that... and Marco says single braces clash with dxgettext too much...

or iif-ithen-ielse ? in double braces ...

Regards, Sven

Kind Regards
el es

OK.

And please remember, we do not NEED this construct; the added value is marginal as I indicated.

OK; I am not normally programming anything in any of the above... but the goal I believe wasn't to just add something that is directly translatable, by copy-paste ?

Simply not adding is an option. Not all change is necessarily progress.

True. and very true.

Michael.

el es

Well then how about: x *:=* *when* condition true_condition *otherwise*
false_condition;

How this is pascalish.

Andreas

Andreas wrote

Well then how about: x := when condition true_condition otherwise false_condition;

Exactly, I was thinking about some kind of keyword to substitute ? and : to make it pascalish.

But I think it should be something like this:

x := Y inline Z otherwise W;

the keyword needs to be after the condition, not before.

Smells, like perl or python... I almost wrote the 'when version' but... ;)

without clear indication that a value is returned, it's like a statement...

Any other imaginative way to indicate that a construct returns a value, other than using braces...? as 'just braces' will confuse people using _() a lot.

(side note :
x := (when condition use truevalue otherwise falsevalue);

looks more like : keyword before expression template; needs 3 keywords however. and still looks like a statement...

)

Andreas

el es

Jonas has told us to drop this, but please could I ask for a clarification: is that your position, or the core team's?

Dňa 5.2.2016 o 11:50 Lukasz Sokol napísal(a):

It look s very strange to me.

Why not just reuse C:

   x := condition ? truevalue : falsevalue ;

As stated before.
May be only for {$COPERATORS ON}
(So it will not influence Pascal language, but for those who want use it, can enable this syntax using switch)
-Laco.

Il 05/02/2016 10:58, Michael Van Canneyt ha scritto:

+1

C philosophy is to save *typing* time. Pascal philosophy is to save *development* time. Typing is but a small fraction of development. Attempts to save typing usually end up in making the code less readable, and therefore harder to debug, to maintain, to share between developers, etc.

Just my 2 c.

Giuliano

Hello everybody,

Since we're getting back to the same sort of discussion, I'd like to remind three statements (before closing this thread here similarly to the other two):

1) Sven wrote: "There will be *no* replacement in the foreseeable future. This is not up for discussion."

2) Michael wrote: "It is not necessarily permanently off the drawing board, but has definitely been put in the (deep) freezer" (and he also mentioned that the idea might be revived in the future if there's somebody willing to implement a better alternative).

3) Jonas asked to use fpc-other for any further follow-up discussions (the Lazarus forum pointed to by Dimitry is also an option).

Thanks for refraining from continuing the discussion about your preferences regarding how the option not being implemented shall look like on this list (in this thread or another).

Tomas
(one of the FPC mailing list moderators)

[...]

Tomas (one of the FPC mailing list moderators)

Will you or other moderators, accept a request of subscription of fpc-other coming from either automated process on gmane.org or from gmane admins?

I believe fpc-other would be a worthy addition on gmane.org.

(If only to keep the likes of me from ranting)

Not sure whether the signup has to be handled by a moderator, but if so, please do allow posting through gmane too.

If the subscribe/signup by Gmane can be performed by non-admin, I am giving my hands-up for it (might happen today, or somewhere next week, time allowing).

Kind Regards
el es

Lukasz Sokol wrote on Fri, 05 Feb 2016:

Will you or other moderators, accept a request of subscription of fpc-other coming from either automated process on gmane.org or from gmane admins? I believe fpc-other would be a worthy addition on gmane.org.

After your previous mail about this, I filled in the request form on their site. I have heard nothing back.

Jonas

Thanks Jonas.

I never did that before. Maybe they are understaffed ;)

Thanks anyway; Next week we can start poking at their email addresses ;)

Jonas

-L.

Are you new here???

1. Because it's C.
2. Because it looks like C.
3. Because it smells like C.
4. Because it behaves like C.
5. It would actually be useful for making porting C code easier.
6. No 100+ mails thread needed to discuss what the best way is to make it look pascalish and not break code.
7. Did I mention that it is C (and C++, Java, JS)?

For me that is the only syntax I would like to see (and therefore use) it as I am used to it but knowing the pascal community I refrained from participating in the thread and it's really a minor feature.

Hopefully there will never be atrocities like a+=1. ^^

Please never name the unholy language on this list again.

R.

P.S.: It's all good fun, I know that C/C++ are not for everyone.