|
|
12
|
|
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
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
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 - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
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 - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
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 - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
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 - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
On Tue, 2 Feb 2016, Dmitry Boyarintsev wrote:
> On Tue, Feb 2, 2016 at 4:40 PM, geneb < [hidden email]> 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 - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
Am 02.02.2016 22:51 schrieb "geneb" <[hidden email]>:
>
> On Tue, 2 Feb 2016, Dmitry Boyarintsev wrote:
>
>> On Tue, Feb 2, 2016 at 4:40 PM, geneb <[hidden email]> 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 - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
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 - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
On Feb 2, 2016 7:41 PM, "geneb" <[hidden email]> 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 - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
etrusco wrote
On Feb 2, 2016 7:41 PM, "geneb" < [hidden email]> 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;
begin
WriteLn('A');
Result := 10;
end;
function test2: integer;
begin
WriteLn('B');
Result := 20;
end;
function CommonFunc(A: Boolean; B, C: integer): integer;
begin
if A then
Result := B
else
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:
A
10
----
B
A
10
|
|
|
On 03/02/2016 12:00, [hidden email] wrote:
> Date: Tue, 2 Feb 2016 19:43:02 -0700 (MST)
> From: silvioprog< [hidden email]>
>
>> >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; begin WriteLn('A');
> Result := 10; end; function test2: integer; begin WriteLn('B');
> Result := 20; end; function CommonFunc(A: Boolean; B, C: integer):
> integer; begin if A then Result := B else 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:
> A10----BA10
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 - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
Regards,
Serguei
|
12
|
Locked
inline-if-expr.patch (3K)