Re: [fpc-pascal] if-then-else expression

[Serguei TARASSOV]

On 04/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:

Date: Wed, 3 Feb 2016 14:34:34 +0100
From: Sven Barth

Am 03.02.2016 12:11 schrieb "Serguei TARASSOV":
>Holy sh*t, ?a continue !:)
>Even if evaluation order will be assured and well documented, it doesn't make 
sense!

>Example :
>
>x := iif(Obj = nil, 0, Obj.Value); // Seems OK when right-to-left and stop on 
'true' evalation
>x := iif(Obj <> nil, Obj.Value, 0); // Raise access violation

The current IfThen() intrinsic is not a function call. Internally it gets
replaced by an if-node thus from the compiler's point of view it behaves
like an if-statement that assigns the expressions in its branches to a
temporary variable (yes that one is thrown away during code generation...),
thus the term evaluation order in the sense of calling functions does not
apply at all anyway.

I see, and it is what I said many times: you wrap the if-statement into 
pseudo-function.

This make no sense and will be source of programmer's errors.
The simplest case is to add "uses Math" or "uses StrUtils" to hide 
intrinsic pseudo-function and crash the application.


iif bool-expression then expression-true else expression-false;
or
inline if bool-expression then expression-true else expression-false;

is only solution in my opinion.

Regards,
Serguei
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Jonas Maebe]

On 04/02/16 12:36, Serguei TARASSOV wrote:

I see, and it is what I said many times


And since this is now becoming a thread in which mostly things from the 
previous one are repeated, please also move it to the fpc-other list.


Thanks,


Jonas
FPC mailing lists admin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[silvioprog]

On Wed, Feb 3, 2016 at 8:11 AM, Serguei TARASSOV  wrote:

> On 03/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:
>
>> Date: Tue, 2 Feb 2016 19:43:02 -0700 (MST)
>> From: silvioprog
>>
>> >The problem with Iff() is:1) it either retains normal function behavior
>>> >and thus has to evaluate both expressions (i.e. suboptimal performance
>>> and
>>> >allowing side effects);
>>>
>> Well:
>> program Project1;  function test1: integer;  beginWriteLn('A');
>> Result := 10;  end;  function test2: integer;  beginWriteLn('B');
>> Result := 20;  end;  function CommonFunc(A: Boolean; B, C: integer):
>> integer;  beginif A then  Result := Belse  Result := C;
>> end;var  X: LongInt;begin  X := IfThen(True, test1, test2);  WriteLn(X);
>> WriteLn('');  X := CommonFunc(True, test1, test2);  WriteLn(X);
>> ReadLn;end.
>> Result:
>> A10BA10
>>
> Holy sh*t, ça continue ! :)
>

:-)


> Even if evaluation order will be assured and well documented, it doesn't
> make sense!
> Example :
>
> x := iif(Obj = nil, 0, Obj.Value); // Seems OK when right-to-left and stop
> on 'true' evalation
> x := iif(Obj <> nil, Obj.Value, 0); // Raise access violation


Did you test it? Using the current System.IfThen() it doesn't raises AV for
me.

-- 
Silvio Clécio
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Serguei TARASSOV]

On 03/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:

Date: Tue, 2 Feb 2016 19:43:02 -0700 (MST)
From: silvioprog


>The problem with Iff() is:1) it either retains normal function behavior
>and thus has to evaluate both expressions (i.e. suboptimal performance and
>allowing side effects);

Well:
program Project1;  function test1: integer;  beginWriteLn('A');
Result := 10;  end;  function test2: integer;  beginWriteLn('B');
Result := 20;  end;  function CommonFunc(A: Boolean; B, C: integer):
integer;  beginif A then  Result := Belse  Result := C;
end;var  X: LongInt;begin  X := IfThen(True, test1, test2);  WriteLn(X);
WriteLn('');  X := CommonFunc(True, test1, test2);  WriteLn(X);
ReadLn;end.
Result:
A10BA10

Holy sh*t, ça continue ! :)
Even if evaluation order will be assured and well documented, it doesn't 
make sense!

Example :

x := iif(Obj = nil, 0, Obj.Value); // Seems OK when right-to-left and 
stop on 'true' evalation

x := iif(Obj <> nil, Obj.Value, 0); // Raise access violation

Regards,
Serguei
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Dmitry Boyarintsev]

On Wed, Feb 3, 2016 at 6:11 AM, Serguei TARASSOV  wrote:

> Holy sh*t, ça continue ! :)
>

it's finally on the forum as well
http://forum.lazarus.freepascal.org/index.php/topic,31367.msg200825/topicseen.html#new

thanks,
Dmitry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Sven Barth]

Am 03.02.2016 12:11 schrieb "Serguei TARASSOV" :
>
> On 03/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:
>>
>> Date: Tue, 2 Feb 2016 19:43:02 -0700 (MST)
>> From: silvioprog
>>
>>
>>> >The problem with Iff() is:1) it either retains normal function behavior
>>> >and thus has to evaluate both expressions (i.e. suboptimal performance
and
>>> >allowing side effects);
>>
>> Well:
>> program Project1;  function test1: integer;  beginWriteLn('A');
>> Result := 10;  end;  function test2: integer;  beginWriteLn('B');
>> Result := 20;  end;  function CommonFunc(A: Boolean; B, C: integer):
>> integer;  beginif A then  Result := Belse  Result := C;
>> end;var  X: LongInt;begin  X := IfThen(True, test1, test2);  WriteLn(X);
>> WriteLn('');  X := CommonFunc(True, test1, test2);  WriteLn(X);
>> ReadLn;end.
>> Result:
>> A10BA10
>
> Holy sh*t, ça continue ! :)
> Even if evaluation order will be assured and well documented, it doesn't
make sense!
> Example :
>
> x := iif(Obj = nil, 0, Obj.Value); // Seems OK when right-to-left and
stop on 'true' evalation
> x := iif(Obj <> nil, Obj.Value, 0); // Raise access violation

The current IfThen() intrinsic is not a function call. Internally it gets
replaced by an if-node thus from the compiler's point of view it behaves
like an if-statement that assigns the expressions in its branches to a
temporary variable (yes that one is thrown away during code generation...),
thus the term evaluation order in the sense of calling functions does not
apply at all anyway.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Michael Schnell]

On 02/01/2016 09:35 PM, Maciej Izak wrote:



x := if true then 0 else 1


Here a keyword and a statement just optionally returns a value, Same is 
ignored in all legacy code but can be use it you want to and do know 
what you do.


Additionally "0" now is a statement, (optionally) extending what is 
considered a statement.




This is a rather drastic change in the basic definition of the language, 
but might be doable. I's completely optional, and I don't see how it 
might break anything.


But of course the paradigm would ask for being extended to many or all 
other keywords.


An obvious example is "case".

-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Sven Barth]

On 02.02.2016 10:25, Michael Schnell wrote:
> On 02/01/2016 09:35 PM, Maciej Izak wrote:
>>
>>
>> x := if true then 0 else 1
> 
> Here a keyword and a statement just optionally returns a value, Same is
> ignored in all legacy code but can be use it you want to and do know
> what you do.
> 
> Additionally "0" now is a statement, (optionally) extending what is
> considered a statement.

Why would "0" now be a statement? As long as the "if" is the expression
as well then the definition would be "if Condition then ThenExpr else
ElseExpr", not "if Condition then ThenStmt else ElseStmt". Otherwise
things like procedures ore assignments would be allowed as well which is
not the case.

> 
> This is a rather drastic change in the basic definition of the language,
> but might be doable. I's completely optional, and I don't see how it
> might break anything.

Of course it's doable. See the patch I attached at the initial mail of
this thread.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Sven Barth]

On 02.02.2016 20:22, John Lee wrote:
> So (Sven) to clarify, assume that your original ifthen [patch is now in
> latest svn compiler although more work will needed to do x:=if a then b
> else c;? j 

The IfThen() is in trunk though it will at least be renamed.
The if-then-else expression would in theory be good to go as well. Just
look at the first message of this thread for the patch to play around
with it.

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Dmitry Boyarintsev]

On Tue, Feb 2, 2016 at 4:07 PM, geneb  wrote:

I probably missed it, but what problem is "IfThen()" actually solving?
>
> It's a sugar syntax, for

if cond then
  x:= a
else
  x:=b;

Just follow this thread:
http://lists.freepascal.org/pipermail/fpc-pascal/2016-January/046375.html

Pro #1: shortness of script
Pro #2: easier porting of C-style code (with ternary ? operator. Pascal
doesn't have an equivalent
https://en.wikipedia.org/wiki/%3F:#Programming_languages_without_the_conditional_operator
)

thanks,
Dmitry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[John Lee]

So (Sven) to clarify, assume that your original ifthen [patch is now in
latest svn compiler although more work will needed to do x:=if a then b
else c;? j

On 2 February 2016 at 18:33, Sven Barth  wrote:

> On 02.02.2016 10:25, Michael Schnell wrote:
> > On 02/01/2016 09:35 PM, Maciej Izak wrote:
> >>
> >>
> >> x := if true then 0 else 1
> >
> > Here a keyword and a statement just optionally returns a value, Same is
> > ignored in all legacy code but can be use it you want to and do know
> > what you do.
> >
> > Additionally "0" now is a statement, (optionally) extending what is
> > considered a statement.
>
> Why would "0" now be a statement? As long as the "if" is the expression
> as well then the definition would be "if Condition then ThenExpr else
> ElseExpr", not "if Condition then ThenStmt else ElseStmt". Otherwise
> things like procedures ore assignments would be allowed as well which is
> not the case.
>
> >
> > This is a rather drastic change in the basic definition of the language,
> > but might be doable. I's completely optional, and I don't see how it
> > might break anything.
>
> Of course it's doable. See the patch I attached at the initial mail of
> this thread.
>
> Regards,
> Sven
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Sven Barth]

Am 02.02.2016 22:51 schrieb "geneb" :
>
> On Tue, 2 Feb 2016, Dmitry Boyarintsev wrote:
>
>> On Tue, Feb 2, 2016 at 4:40 PM, geneb  wrote:
>>
>>> So it's not solving a /problem/ it's lessening an inconvienence(sp!).
>>>
>>> I would've gone with IIf(). :)
>>>
>>
>> Just keep in mind that the thread (about preferences) is closed.
>
> You can't "close" a discussion thread on an email list. :)

Yes, you can, because mails towards the list can be set to be moderated
based on different criteria and I bet that the thread ID is one of them.
Jonas (as list admin) probably did just that.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[geneb]

On Tue, 2 Feb 2016, Sven Barth wrote:


Yes, you can, because mails towards the list can be set to be moderated
based on different criteria and I bet that the thread ID is one of them.
Jonas (as list admin) probably did just that.

Mailman (at least version 2.1.20, which is what I run) doesn't work like 
that.


g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[geneb]

On Tue, 2 Feb 2016, Sven Barth wrote:


On 02.02.2016 20:22, John Lee wrote:

So (Sven) to clarify, assume that your original ifthen [patch is now in
latest svn compiler although more work will needed to do x:=if a then b
else c;? j


The IfThen() is in trunk though it will at least be renamed.
The if-then-else expression would in theory be good to go as well. Just
look at the first message of this thread for the patch to play around
with it.


I probably missed it, but what problem is "IfThen()" actually solving?

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[John Lee]

Based on Florian's recent emails the if then else is ok, so guess we should
be close to getting it all running. Great, thanks for your efforts. j

On 2 February 2016 at 20:55, Sven Barth  wrote:

> On 02.02.2016 20:22, John Lee wrote:
> > So (Sven) to clarify, assume that your original ifthen [patch is now in
> > latest svn compiler although more work will needed to do x:=if a then b
> > else c;? j
>
> The IfThen() is in trunk though it will at least be renamed.
> The if-then-else expression would in theory be good to go as well. Just
> look at the first message of this thread for the patch to play around
> with it.
>
> Regards,
> Sven
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[geneb]

On Tue, 2 Feb 2016, Dmitry Boyarintsev wrote:


On Tue, Feb 2, 2016 at 4:07 PM, geneb  wrote:

I probably missed it, but what problem is "IfThen()" actually solving?


It's a sugar syntax, for


if cond then
 x:= a
else
 x:=b;

Just follow this thread:
http://lists.freepascal.org/pipermail/fpc-pascal/2016-January/046375.html

Pro #1: shortness of script
Pro #2: easier porting of C-style code (with ternary ? operator. Pascal


So it's not solving a /problem/ it's lessening an inconvienence(sp!).

I would've gone with IIf(). :)

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[geneb]

On Tue, 2 Feb 2016, Dmitry Boyarintsev wrote:


On Tue, Feb 2, 2016 at 4:40 PM, geneb  wrote:


So it's not solving a /problem/ it's lessening an inconvienence(sp!).

I would've gone with IIf(). :)



Just keep in mind that the thread (about preferences) is closed.

You can't "close" a discussion thread on an email list. :)


Everyone are welcomed to create poll on the forum. Discussion also goes on
at fpc-other list.


I don't have a dog in the fight, I was just making an observation.

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Flávio Etrusco]

On Feb 2, 2016 7:41 PM, "geneb"  wrote:
>
> (...)
>
> So it's not solving a /problem/ it's lessening an inconvienence(sp!).
>
> I would've gone with IIf(). :)
>
>
> g.
>

The problem with Iff() is:
1) it either retains normal function behavior and thus has to evaluate both
expressions (i.e. suboptimal performance and allowing side effects);
2) or add inconsistency by using function syntax but different behavior.

Best regards,
Flávio
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[silvioprog]

etrusco wrote
> On Feb 2, 2016 7:41 PM, "geneb" 

> geneb@

>  wrote:
> [...]
> The problem with Iff() is:1) it either retains normal function behavior
> and thus has to evaluate both expressions (i.e. suboptimal performance and
> allowing side effects);

Well:
program Project1;  function test1: integer;  beginWriteLn('A');   
Result := 10;  end;  function test2: integer;  beginWriteLn('B');   
Result := 20;  end;  function CommonFunc(A: Boolean; B, C: integer):
integer;  beginif A then  Result := Belse  Result := C; 
end;var  X: LongInt;begin  X := IfThen(True, test1, test2);  WriteLn(X); 
WriteLn('');  X := CommonFunc(True, test1, test2);  WriteLn(X); 
ReadLn;end.
Result:
A10BA10




--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Re-if-then-else-expression-tp5723834p5723966.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Maciej Izak]

2016-02-01 21:16 GMT+01:00 Sven Barth :

> On 01.02.2016 21:14, Sven Barth wrote:
> > Time for the next flame.


Flame? :O It was constructive discussion :)

For me

x := if true then 0 else 1

is ideal and compatible with Oxygene. +1 IMO no need to any other
combination.

Maybe is time to start developing {$MODE OXYGENE} ?

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[Sven Barth]

On 01.02.2016 21:14, Sven Barth wrote:
> Hello together!
> 
> Time for the next flame. I've attached a patch which implements an "if
> Condition then ThenExpr else ElseExpr"-expression for those that want to
> play around with it. It follows the same principles as the
> yet-to-be-renamed IfThen() (namely that the type is determined by the
> ThenExpr) as it's just a different syntax with the same (copy & pasted)
> code behind it...
> 
> Note: this patch *might* also work with 3.0.0 or even 2.6.4...

And I just noticed that I sent this to fpc-devel instead of
fpc-pascal... *sigh*

So here it is again for fpc-pascal as well.

Regards,
Sven

Index: compiler/pexpr.pas
===
--- compiler/pexpr.pas	(Revision 33036)
+++ compiler/pexpr.pas	(Arbeitskopie)
@@ -3242,6 +3242,77 @@
result:=not current_procinfo.get_normal_proc.procdef.no_self_node;
  end;
 
+
+ function factor_read_inline_if:tnode;
+   var
+ stat : tstatementnode;
+ tempnode : ttempcreatenode;
+ ifnode,
+ condexpr,
+ thenexpr,
+ elseexpr : tnode;
+ resdef : tdef;
+   begin
+ consume(_IF);
+ condexpr:=comp_expr([ef_accept_equal]);
+ consume(_THEN);
+ thenexpr:=comp_expr([ef_accept_equal]);
+ consume(_ELSE);
+ elseexpr:=comp_expr([ef_accept_equal]);
+
+ typecheckpass(condexpr);
+ typecheckpass(thenexpr);
+ typecheckpass(elseexpr);
+
+ if (condexpr.nodetype=errorn) or
+ (thenexpr.nodetype=errorn) or
+ (elseexpr.nodetype=errorn) then
+   result:=cerrornode.create;
+
+ { The result type of the expression is that of the then-expression; the
+   else-expression is converted to that if possible (otherwise error)
+   There are a few special cases however:
+   - constant strings need to be converted to strings
+   - chars need to be checked with strings
+ }
+
+ if is_conststringnode(thenexpr) then
+   begin
+ if is_constwidestringnode(elseexpr) or is_constwidecharnode(elseexpr) then
+   resdef:=cwidestringtype
+ else
+   resdef:=cansistringtype;
+   end
+ else if is_constcharnode(thenexpr) then
+   begin
+ if is_constcharnode(elseexpr) then
+   resdef:=cansichartype
+ else if is_constwidecharnode(elseexpr) then
+   resdef:=cwidechartype
+ else if is_string(elseexpr.resultdef) then
+   resdef:=elseexpr.resultdef
+ else
+   resdef:=thenexpr.resultdef;
+   end
+ else
+   resdef:=thenexpr.resultdef;
+
+ result:=internalstatements(stat);
+
+ { create the tempnode that will hold our result }
+ tempnode:=ctempcreatenode.create(resdef,resdef.size,tt_persistent,true);
+ addstatement(stat,tempnode);
+
+ ifnode:=cifnode.create(condexpr,
+cassignmentnode.create(ctemprefnode.create(tempnode),thenexpr),
+cassignmentnode.create(ctemprefnode.create(tempnode),elseexpr)
+  );
+ addstatement(stat,ifnode);
+
+ addstatement(stat,ctempdeletenode.create_normal_temp(tempnode));
+ addstatement(stat,ctemprefnode.create(tempnode));
+   end;
+
   {-
   Factor (Main)
   -}
@@ -3779,6 +3850,10 @@
consume(_RKLAMMER);
p1:=cinlinenode.create(in_objc_protocol_x,false,p1);
  end;
+   _IF:
+ begin
+   p1:=factor_read_inline_if;
+ end;
 
  else
begin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] if-then-else expression

[silvioprog]

On Mon, Feb 1, 2016 at 5:35 PM, Maciej Izak  wrote:

> 2016-02-01 21:16 GMT+01:00 Sven Barth :
>
>> On 01.02.2016 21:14, Sven Barth wrote:
>> > Time for the next flame.
>
>
> Flame? :O It was constructive discussion :)
>

+1. It was constructive discussion.

For me
>
> x := if true then 0 else 1
>

For me, no problem extending ObjFPC to make a new abbreviated Pascal
language, however, will be IfThen() function kept? (or something like this)


> is ideal and compatible with Oxygene. +1 IMO no need to any other
> combination.
>
> Maybe is time to start developing {$MODE OXYGENE} ?
>

-- 
Silvio Clécio
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal