Is it possible to turn a statement into a expression?
In C, you can assign two variables in one line with
b = a = sqrt(10);
In Delphi
b := a := Sqrt(10);
is not allowed.
With IfThen
, there is an "alternative" for the ternary operator ?:
as discussed in Delphi - Equivalent to C#'s ternary operator? In summary, IfThen
doesn't seem absolutely necessary.
So maybe there is also something like this:
function AssignAndReturn(var LHS: Integer; RHS: Integer): Integer;
begin
LHS := RHS;
Result := RHS;
end;
(...)
var
a, b: Integer;
begin
b := AssignAndReturn(a, Round(Sqrt(10)));
I'm not trying to "make everything look like C". I just noticed, that sometimes it would be nice to "reuse" the right hand side of an assignment in the same line again. (See Lazarus/Free Pascal: How to improve coding style (to avoid using endless loop) of a while loop whose boolean expression is reassigned every pass for example.)
delphi pascal lazarus freepascal turbo-pascal
add a comment |
In C, you can assign two variables in one line with
b = a = sqrt(10);
In Delphi
b := a := Sqrt(10);
is not allowed.
With IfThen
, there is an "alternative" for the ternary operator ?:
as discussed in Delphi - Equivalent to C#'s ternary operator? In summary, IfThen
doesn't seem absolutely necessary.
So maybe there is also something like this:
function AssignAndReturn(var LHS: Integer; RHS: Integer): Integer;
begin
LHS := RHS;
Result := RHS;
end;
(...)
var
a, b: Integer;
begin
b := AssignAndReturn(a, Round(Sqrt(10)));
I'm not trying to "make everything look like C". I just noticed, that sometimes it would be nice to "reuse" the right hand side of an assignment in the same line again. (See Lazarus/Free Pascal: How to improve coding style (to avoid using endless loop) of a while loop whose boolean expression is reassigned every pass for example.)
delphi pascal lazarus freepascal turbo-pascal
Did you look at the source to see how IfThen is implemented? (I'm not the close voter, BTW)
– Ken White
Jun 20 '16 at 22:27
1
@muschL: What exactly are you asking for ? This example shows a function which assigns to some variable and also returns the result, but this does not explain why you could not simply assign to the variable that you pass to the function and use that variable where you would have used the function return value. For more helpful responses, instead of showing a solution and asking a question which makes little sense on its own, explain what problem your solution is trying to solve, why you consider it inadequate and what you are trying to achieve that your solution currently does not.
– Deltics
Jun 20 '16 at 23:18
2
Delphi's IfThen is not equivalent to the C ternary operator. Try it with functions that have side effects on both sides and you'll see the difference. Your edit clarifies what you're asking, but I fail to see the point. Your mess with AssignAndReturn in your final example is horrific, and two separate lines of code to accomplish the same thing would be much more readable and maintainable. I fail to understand why people want to obfuscate or deface code by converting everything to look like C.
– Ken White
Jun 20 '16 at 23:54
1
In Pascal:=
isn't an operator and doesn't return a l-value. This is by design. Your current solution is only possible way to do as you want.
– Free Consulting
Jun 21 '16 at 0:38
3
Regarding the edit,IfThen
is not equivalent to anif then else
statement. Only one branch of theif then else
is executed. All arguments to theIfThen
function are evaluated. Secondly, you already have an answer to your question. It is a simple "no". Thirdly, the reason people are criticising your proposed function is that it is a very bad idea to implement and use such a function. Do expect people to give you advice. Then it's up to you to decide how to react to that advice.
– David Heffernan
Jun 21 '16 at 8:39
add a comment |
In C, you can assign two variables in one line with
b = a = sqrt(10);
In Delphi
b := a := Sqrt(10);
is not allowed.
With IfThen
, there is an "alternative" for the ternary operator ?:
as discussed in Delphi - Equivalent to C#'s ternary operator? In summary, IfThen
doesn't seem absolutely necessary.
So maybe there is also something like this:
function AssignAndReturn(var LHS: Integer; RHS: Integer): Integer;
begin
LHS := RHS;
Result := RHS;
end;
(...)
var
a, b: Integer;
begin
b := AssignAndReturn(a, Round(Sqrt(10)));
I'm not trying to "make everything look like C". I just noticed, that sometimes it would be nice to "reuse" the right hand side of an assignment in the same line again. (See Lazarus/Free Pascal: How to improve coding style (to avoid using endless loop) of a while loop whose boolean expression is reassigned every pass for example.)
delphi pascal lazarus freepascal turbo-pascal
In C, you can assign two variables in one line with
b = a = sqrt(10);
In Delphi
b := a := Sqrt(10);
is not allowed.
With IfThen
, there is an "alternative" for the ternary operator ?:
as discussed in Delphi - Equivalent to C#'s ternary operator? In summary, IfThen
doesn't seem absolutely necessary.
So maybe there is also something like this:
function AssignAndReturn(var LHS: Integer; RHS: Integer): Integer;
begin
LHS := RHS;
Result := RHS;
end;
(...)
var
a, b: Integer;
begin
b := AssignAndReturn(a, Round(Sqrt(10)));
I'm not trying to "make everything look like C". I just noticed, that sometimes it would be nice to "reuse" the right hand side of an assignment in the same line again. (See Lazarus/Free Pascal: How to improve coding style (to avoid using endless loop) of a while loop whose boolean expression is reassigned every pass for example.)
delphi pascal lazarus freepascal turbo-pascal
delphi pascal lazarus freepascal turbo-pascal
edited Dec 27 '18 at 14:50
asked Jun 20 '16 at 21:56
Jayjayyy
2,26221827
2,26221827
Did you look at the source to see how IfThen is implemented? (I'm not the close voter, BTW)
– Ken White
Jun 20 '16 at 22:27
1
@muschL: What exactly are you asking for ? This example shows a function which assigns to some variable and also returns the result, but this does not explain why you could not simply assign to the variable that you pass to the function and use that variable where you would have used the function return value. For more helpful responses, instead of showing a solution and asking a question which makes little sense on its own, explain what problem your solution is trying to solve, why you consider it inadequate and what you are trying to achieve that your solution currently does not.
– Deltics
Jun 20 '16 at 23:18
2
Delphi's IfThen is not equivalent to the C ternary operator. Try it with functions that have side effects on both sides and you'll see the difference. Your edit clarifies what you're asking, but I fail to see the point. Your mess with AssignAndReturn in your final example is horrific, and two separate lines of code to accomplish the same thing would be much more readable and maintainable. I fail to understand why people want to obfuscate or deface code by converting everything to look like C.
– Ken White
Jun 20 '16 at 23:54
1
In Pascal:=
isn't an operator and doesn't return a l-value. This is by design. Your current solution is only possible way to do as you want.
– Free Consulting
Jun 21 '16 at 0:38
3
Regarding the edit,IfThen
is not equivalent to anif then else
statement. Only one branch of theif then else
is executed. All arguments to theIfThen
function are evaluated. Secondly, you already have an answer to your question. It is a simple "no". Thirdly, the reason people are criticising your proposed function is that it is a very bad idea to implement and use such a function. Do expect people to give you advice. Then it's up to you to decide how to react to that advice.
– David Heffernan
Jun 21 '16 at 8:39
add a comment |
Did you look at the source to see how IfThen is implemented? (I'm not the close voter, BTW)
– Ken White
Jun 20 '16 at 22:27
1
@muschL: What exactly are you asking for ? This example shows a function which assigns to some variable and also returns the result, but this does not explain why you could not simply assign to the variable that you pass to the function and use that variable where you would have used the function return value. For more helpful responses, instead of showing a solution and asking a question which makes little sense on its own, explain what problem your solution is trying to solve, why you consider it inadequate and what you are trying to achieve that your solution currently does not.
– Deltics
Jun 20 '16 at 23:18
2
Delphi's IfThen is not equivalent to the C ternary operator. Try it with functions that have side effects on both sides and you'll see the difference. Your edit clarifies what you're asking, but I fail to see the point. Your mess with AssignAndReturn in your final example is horrific, and two separate lines of code to accomplish the same thing would be much more readable and maintainable. I fail to understand why people want to obfuscate or deface code by converting everything to look like C.
– Ken White
Jun 20 '16 at 23:54
1
In Pascal:=
isn't an operator and doesn't return a l-value. This is by design. Your current solution is only possible way to do as you want.
– Free Consulting
Jun 21 '16 at 0:38
3
Regarding the edit,IfThen
is not equivalent to anif then else
statement. Only one branch of theif then else
is executed. All arguments to theIfThen
function are evaluated. Secondly, you already have an answer to your question. It is a simple "no". Thirdly, the reason people are criticising your proposed function is that it is a very bad idea to implement and use such a function. Do expect people to give you advice. Then it's up to you to decide how to react to that advice.
– David Heffernan
Jun 21 '16 at 8:39
Did you look at the source to see how IfThen is implemented? (I'm not the close voter, BTW)
– Ken White
Jun 20 '16 at 22:27
Did you look at the source to see how IfThen is implemented? (I'm not the close voter, BTW)
– Ken White
Jun 20 '16 at 22:27
1
1
@muschL: What exactly are you asking for ? This example shows a function which assigns to some variable and also returns the result, but this does not explain why you could not simply assign to the variable that you pass to the function and use that variable where you would have used the function return value. For more helpful responses, instead of showing a solution and asking a question which makes little sense on its own, explain what problem your solution is trying to solve, why you consider it inadequate and what you are trying to achieve that your solution currently does not.
– Deltics
Jun 20 '16 at 23:18
@muschL: What exactly are you asking for ? This example shows a function which assigns to some variable and also returns the result, but this does not explain why you could not simply assign to the variable that you pass to the function and use that variable where you would have used the function return value. For more helpful responses, instead of showing a solution and asking a question which makes little sense on its own, explain what problem your solution is trying to solve, why you consider it inadequate and what you are trying to achieve that your solution currently does not.
– Deltics
Jun 20 '16 at 23:18
2
2
Delphi's IfThen is not equivalent to the C ternary operator. Try it with functions that have side effects on both sides and you'll see the difference. Your edit clarifies what you're asking, but I fail to see the point. Your mess with AssignAndReturn in your final example is horrific, and two separate lines of code to accomplish the same thing would be much more readable and maintainable. I fail to understand why people want to obfuscate or deface code by converting everything to look like C.
– Ken White
Jun 20 '16 at 23:54
Delphi's IfThen is not equivalent to the C ternary operator. Try it with functions that have side effects on both sides and you'll see the difference. Your edit clarifies what you're asking, but I fail to see the point. Your mess with AssignAndReturn in your final example is horrific, and two separate lines of code to accomplish the same thing would be much more readable and maintainable. I fail to understand why people want to obfuscate or deface code by converting everything to look like C.
– Ken White
Jun 20 '16 at 23:54
1
1
In Pascal
:=
isn't an operator and doesn't return a l-value. This is by design. Your current solution is only possible way to do as you want.– Free Consulting
Jun 21 '16 at 0:38
In Pascal
:=
isn't an operator and doesn't return a l-value. This is by design. Your current solution is only possible way to do as you want.– Free Consulting
Jun 21 '16 at 0:38
3
3
Regarding the edit,
IfThen
is not equivalent to an if then else
statement. Only one branch of the if then else
is executed. All arguments to the IfThen
function are evaluated. Secondly, you already have an answer to your question. It is a simple "no". Thirdly, the reason people are criticising your proposed function is that it is a very bad idea to implement and use such a function. Do expect people to give you advice. Then it's up to you to decide how to react to that advice.– David Heffernan
Jun 21 '16 at 8:39
Regarding the edit,
IfThen
is not equivalent to an if then else
statement. Only one branch of the if then else
is executed. All arguments to the IfThen
function are evaluated. Secondly, you already have an answer to your question. It is a simple "no". Thirdly, the reason people are criticising your proposed function is that it is a very bad idea to implement and use such a function. Do expect people to give you advice. Then it's up to you to decide how to react to that advice.– David Heffernan
Jun 21 '16 at 8:39
add a comment |
2 Answers
2
active
oldest
votes
The short answer is:
No. What you want is not possible. And arguably would be of little if any benefit in Delphi.
First, let's discuss a more practical example. To be frank, a = b = f(x);
is a rather poor example.
- It's rare that you arbitrarily want the same value assigned to 2 variables.
- Order of operation above has to break the left to right convention otherwise it would first resolve
a = b
then? = f(x)
. - So there's little justification to favour that over
b = f(x); a = b;
. - Basically it's good for byte count (code golf) not readability.
So instead, let's consider the following, more practical scenario:
//Option 1
if ((b = f(x)) > 42)
//use b
There's no Delphi equivalent to the above, but it's at least as readable/maintainable to write:
//Option 2
b := f(x);
if (b > 42) then
//use b
There is another option to consider; especially if Option 1 is sitting in the middle of a larger function. Remember small functions are more maintainable and easier for a compiler to optimise. So consider:
//Option 3
...
ProcessRule42(f(x));
...
//Where Rule42 is is implemented as:
procedure ProcessRule42(b: Integer);
begin
if (b > 42) then
//use b
end;
Delphi doesn't really seem to be suffering due to not being able to write: if (b := f(x)) > 42 then //use b
.
Is there any real benefit to Option 1?
If the Option 2 is at least as good, why would one ever bother with Option 1. The benefit is seen when you consider scoping rules.
//b does not exist
if ((var b = f(x)) > 42) {
//use b
}
//b does not exist
// Using the Delphi approach, this becomes:
//b does not exist
var b = f(x);
if (b > 42) {
//use b
}
//b still exists
Delphi simply does not have the same scoping concerns. Delphi variables are all declared at the beginning of the method, and available for the whole method.
Conclusion
This brings us back to what others have been trying to explain. Delphi is a different language with slightly different approaches to some problems. While I applaud you for examining other options and considering what concepts can be borrowed from other languages: be careful of trying to force-fit some concepts where they don't belong.
If you break too many Delphi paradigms, your code may become unnecessarily difficult for Delphi programmers to maintain.
1
Also,b = a = fx()
as well asif (b = a)
are vulnerable to trivial typing errors resulting in substantive behavioural differences. i.e. what if you had really intended to writeb = a == fx()
orif (b ==a)
? The syntax of Pascal explicitly is intended to avoid such problems and clearly distinguishing between statements and expressions is part of that, and A Good Thing, imho. The "Pascal Way" to do this would be to allow a comma list of variables on the LHS of an assignment, thereby retaining the statement/expression distinction while allowing multiple simultaneous assignment.
– Deltics
Jun 21 '16 at 21:00
add a comment |
An assignment statement is not an expression. It does not, and will never, yield a value. The only way to assign to multiple variables in one statement is via a function.
Based on this question and your previous question I would say that you are mistaken in trying to fight against the language. Code into the language you are using. In C you might write
b = a = sqrt(10);
But in Pascal the language wants you to write it like this
a := sqrt(10);
b := a;
Do it this way. Don't create obscure functions just so that you can cram it all onto a single line. The two lines above could not be clearer to read. Stop trying to force other languages into Pascal. They don't fit.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f37932462%2fis-it-possible-to-turn-a-statement-into-a-expression%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The short answer is:
No. What you want is not possible. And arguably would be of little if any benefit in Delphi.
First, let's discuss a more practical example. To be frank, a = b = f(x);
is a rather poor example.
- It's rare that you arbitrarily want the same value assigned to 2 variables.
- Order of operation above has to break the left to right convention otherwise it would first resolve
a = b
then? = f(x)
. - So there's little justification to favour that over
b = f(x); a = b;
. - Basically it's good for byte count (code golf) not readability.
So instead, let's consider the following, more practical scenario:
//Option 1
if ((b = f(x)) > 42)
//use b
There's no Delphi equivalent to the above, but it's at least as readable/maintainable to write:
//Option 2
b := f(x);
if (b > 42) then
//use b
There is another option to consider; especially if Option 1 is sitting in the middle of a larger function. Remember small functions are more maintainable and easier for a compiler to optimise. So consider:
//Option 3
...
ProcessRule42(f(x));
...
//Where Rule42 is is implemented as:
procedure ProcessRule42(b: Integer);
begin
if (b > 42) then
//use b
end;
Delphi doesn't really seem to be suffering due to not being able to write: if (b := f(x)) > 42 then //use b
.
Is there any real benefit to Option 1?
If the Option 2 is at least as good, why would one ever bother with Option 1. The benefit is seen when you consider scoping rules.
//b does not exist
if ((var b = f(x)) > 42) {
//use b
}
//b does not exist
// Using the Delphi approach, this becomes:
//b does not exist
var b = f(x);
if (b > 42) {
//use b
}
//b still exists
Delphi simply does not have the same scoping concerns. Delphi variables are all declared at the beginning of the method, and available for the whole method.
Conclusion
This brings us back to what others have been trying to explain. Delphi is a different language with slightly different approaches to some problems. While I applaud you for examining other options and considering what concepts can be borrowed from other languages: be careful of trying to force-fit some concepts where they don't belong.
If you break too many Delphi paradigms, your code may become unnecessarily difficult for Delphi programmers to maintain.
1
Also,b = a = fx()
as well asif (b = a)
are vulnerable to trivial typing errors resulting in substantive behavioural differences. i.e. what if you had really intended to writeb = a == fx()
orif (b ==a)
? The syntax of Pascal explicitly is intended to avoid such problems and clearly distinguishing between statements and expressions is part of that, and A Good Thing, imho. The "Pascal Way" to do this would be to allow a comma list of variables on the LHS of an assignment, thereby retaining the statement/expression distinction while allowing multiple simultaneous assignment.
– Deltics
Jun 21 '16 at 21:00
add a comment |
The short answer is:
No. What you want is not possible. And arguably would be of little if any benefit in Delphi.
First, let's discuss a more practical example. To be frank, a = b = f(x);
is a rather poor example.
- It's rare that you arbitrarily want the same value assigned to 2 variables.
- Order of operation above has to break the left to right convention otherwise it would first resolve
a = b
then? = f(x)
. - So there's little justification to favour that over
b = f(x); a = b;
. - Basically it's good for byte count (code golf) not readability.
So instead, let's consider the following, more practical scenario:
//Option 1
if ((b = f(x)) > 42)
//use b
There's no Delphi equivalent to the above, but it's at least as readable/maintainable to write:
//Option 2
b := f(x);
if (b > 42) then
//use b
There is another option to consider; especially if Option 1 is sitting in the middle of a larger function. Remember small functions are more maintainable and easier for a compiler to optimise. So consider:
//Option 3
...
ProcessRule42(f(x));
...
//Where Rule42 is is implemented as:
procedure ProcessRule42(b: Integer);
begin
if (b > 42) then
//use b
end;
Delphi doesn't really seem to be suffering due to not being able to write: if (b := f(x)) > 42 then //use b
.
Is there any real benefit to Option 1?
If the Option 2 is at least as good, why would one ever bother with Option 1. The benefit is seen when you consider scoping rules.
//b does not exist
if ((var b = f(x)) > 42) {
//use b
}
//b does not exist
// Using the Delphi approach, this becomes:
//b does not exist
var b = f(x);
if (b > 42) {
//use b
}
//b still exists
Delphi simply does not have the same scoping concerns. Delphi variables are all declared at the beginning of the method, and available for the whole method.
Conclusion
This brings us back to what others have been trying to explain. Delphi is a different language with slightly different approaches to some problems. While I applaud you for examining other options and considering what concepts can be borrowed from other languages: be careful of trying to force-fit some concepts where they don't belong.
If you break too many Delphi paradigms, your code may become unnecessarily difficult for Delphi programmers to maintain.
1
Also,b = a = fx()
as well asif (b = a)
are vulnerable to trivial typing errors resulting in substantive behavioural differences. i.e. what if you had really intended to writeb = a == fx()
orif (b ==a)
? The syntax of Pascal explicitly is intended to avoid such problems and clearly distinguishing between statements and expressions is part of that, and A Good Thing, imho. The "Pascal Way" to do this would be to allow a comma list of variables on the LHS of an assignment, thereby retaining the statement/expression distinction while allowing multiple simultaneous assignment.
– Deltics
Jun 21 '16 at 21:00
add a comment |
The short answer is:
No. What you want is not possible. And arguably would be of little if any benefit in Delphi.
First, let's discuss a more practical example. To be frank, a = b = f(x);
is a rather poor example.
- It's rare that you arbitrarily want the same value assigned to 2 variables.
- Order of operation above has to break the left to right convention otherwise it would first resolve
a = b
then? = f(x)
. - So there's little justification to favour that over
b = f(x); a = b;
. - Basically it's good for byte count (code golf) not readability.
So instead, let's consider the following, more practical scenario:
//Option 1
if ((b = f(x)) > 42)
//use b
There's no Delphi equivalent to the above, but it's at least as readable/maintainable to write:
//Option 2
b := f(x);
if (b > 42) then
//use b
There is another option to consider; especially if Option 1 is sitting in the middle of a larger function. Remember small functions are more maintainable and easier for a compiler to optimise. So consider:
//Option 3
...
ProcessRule42(f(x));
...
//Where Rule42 is is implemented as:
procedure ProcessRule42(b: Integer);
begin
if (b > 42) then
//use b
end;
Delphi doesn't really seem to be suffering due to not being able to write: if (b := f(x)) > 42 then //use b
.
Is there any real benefit to Option 1?
If the Option 2 is at least as good, why would one ever bother with Option 1. The benefit is seen when you consider scoping rules.
//b does not exist
if ((var b = f(x)) > 42) {
//use b
}
//b does not exist
// Using the Delphi approach, this becomes:
//b does not exist
var b = f(x);
if (b > 42) {
//use b
}
//b still exists
Delphi simply does not have the same scoping concerns. Delphi variables are all declared at the beginning of the method, and available for the whole method.
Conclusion
This brings us back to what others have been trying to explain. Delphi is a different language with slightly different approaches to some problems. While I applaud you for examining other options and considering what concepts can be borrowed from other languages: be careful of trying to force-fit some concepts where they don't belong.
If you break too many Delphi paradigms, your code may become unnecessarily difficult for Delphi programmers to maintain.
The short answer is:
No. What you want is not possible. And arguably would be of little if any benefit in Delphi.
First, let's discuss a more practical example. To be frank, a = b = f(x);
is a rather poor example.
- It's rare that you arbitrarily want the same value assigned to 2 variables.
- Order of operation above has to break the left to right convention otherwise it would first resolve
a = b
then? = f(x)
. - So there's little justification to favour that over
b = f(x); a = b;
. - Basically it's good for byte count (code golf) not readability.
So instead, let's consider the following, more practical scenario:
//Option 1
if ((b = f(x)) > 42)
//use b
There's no Delphi equivalent to the above, but it's at least as readable/maintainable to write:
//Option 2
b := f(x);
if (b > 42) then
//use b
There is another option to consider; especially if Option 1 is sitting in the middle of a larger function. Remember small functions are more maintainable and easier for a compiler to optimise. So consider:
//Option 3
...
ProcessRule42(f(x));
...
//Where Rule42 is is implemented as:
procedure ProcessRule42(b: Integer);
begin
if (b > 42) then
//use b
end;
Delphi doesn't really seem to be suffering due to not being able to write: if (b := f(x)) > 42 then //use b
.
Is there any real benefit to Option 1?
If the Option 2 is at least as good, why would one ever bother with Option 1. The benefit is seen when you consider scoping rules.
//b does not exist
if ((var b = f(x)) > 42) {
//use b
}
//b does not exist
// Using the Delphi approach, this becomes:
//b does not exist
var b = f(x);
if (b > 42) {
//use b
}
//b still exists
Delphi simply does not have the same scoping concerns. Delphi variables are all declared at the beginning of the method, and available for the whole method.
Conclusion
This brings us back to what others have been trying to explain. Delphi is a different language with slightly different approaches to some problems. While I applaud you for examining other options and considering what concepts can be borrowed from other languages: be careful of trying to force-fit some concepts where they don't belong.
If you break too many Delphi paradigms, your code may become unnecessarily difficult for Delphi programmers to maintain.
edited Jun 22 '16 at 11:32
answered Jun 21 '16 at 15:31
Disillusioned
12.6k23269
12.6k23269
1
Also,b = a = fx()
as well asif (b = a)
are vulnerable to trivial typing errors resulting in substantive behavioural differences. i.e. what if you had really intended to writeb = a == fx()
orif (b ==a)
? The syntax of Pascal explicitly is intended to avoid such problems and clearly distinguishing between statements and expressions is part of that, and A Good Thing, imho. The "Pascal Way" to do this would be to allow a comma list of variables on the LHS of an assignment, thereby retaining the statement/expression distinction while allowing multiple simultaneous assignment.
– Deltics
Jun 21 '16 at 21:00
add a comment |
1
Also,b = a = fx()
as well asif (b = a)
are vulnerable to trivial typing errors resulting in substantive behavioural differences. i.e. what if you had really intended to writeb = a == fx()
orif (b ==a)
? The syntax of Pascal explicitly is intended to avoid such problems and clearly distinguishing between statements and expressions is part of that, and A Good Thing, imho. The "Pascal Way" to do this would be to allow a comma list of variables on the LHS of an assignment, thereby retaining the statement/expression distinction while allowing multiple simultaneous assignment.
– Deltics
Jun 21 '16 at 21:00
1
1
Also,
b = a = fx()
as well as if (b = a)
are vulnerable to trivial typing errors resulting in substantive behavioural differences. i.e. what if you had really intended to write b = a == fx()
or if (b ==a)
? The syntax of Pascal explicitly is intended to avoid such problems and clearly distinguishing between statements and expressions is part of that, and A Good Thing, imho. The "Pascal Way" to do this would be to allow a comma list of variables on the LHS of an assignment, thereby retaining the statement/expression distinction while allowing multiple simultaneous assignment.– Deltics
Jun 21 '16 at 21:00
Also,
b = a = fx()
as well as if (b = a)
are vulnerable to trivial typing errors resulting in substantive behavioural differences. i.e. what if you had really intended to write b = a == fx()
or if (b ==a)
? The syntax of Pascal explicitly is intended to avoid such problems and clearly distinguishing between statements and expressions is part of that, and A Good Thing, imho. The "Pascal Way" to do this would be to allow a comma list of variables on the LHS of an assignment, thereby retaining the statement/expression distinction while allowing multiple simultaneous assignment.– Deltics
Jun 21 '16 at 21:00
add a comment |
An assignment statement is not an expression. It does not, and will never, yield a value. The only way to assign to multiple variables in one statement is via a function.
Based on this question and your previous question I would say that you are mistaken in trying to fight against the language. Code into the language you are using. In C you might write
b = a = sqrt(10);
But in Pascal the language wants you to write it like this
a := sqrt(10);
b := a;
Do it this way. Don't create obscure functions just so that you can cram it all onto a single line. The two lines above could not be clearer to read. Stop trying to force other languages into Pascal. They don't fit.
add a comment |
An assignment statement is not an expression. It does not, and will never, yield a value. The only way to assign to multiple variables in one statement is via a function.
Based on this question and your previous question I would say that you are mistaken in trying to fight against the language. Code into the language you are using. In C you might write
b = a = sqrt(10);
But in Pascal the language wants you to write it like this
a := sqrt(10);
b := a;
Do it this way. Don't create obscure functions just so that you can cram it all onto a single line. The two lines above could not be clearer to read. Stop trying to force other languages into Pascal. They don't fit.
add a comment |
An assignment statement is not an expression. It does not, and will never, yield a value. The only way to assign to multiple variables in one statement is via a function.
Based on this question and your previous question I would say that you are mistaken in trying to fight against the language. Code into the language you are using. In C you might write
b = a = sqrt(10);
But in Pascal the language wants you to write it like this
a := sqrt(10);
b := a;
Do it this way. Don't create obscure functions just so that you can cram it all onto a single line. The two lines above could not be clearer to read. Stop trying to force other languages into Pascal. They don't fit.
An assignment statement is not an expression. It does not, and will never, yield a value. The only way to assign to multiple variables in one statement is via a function.
Based on this question and your previous question I would say that you are mistaken in trying to fight against the language. Code into the language you are using. In C you might write
b = a = sqrt(10);
But in Pascal the language wants you to write it like this
a := sqrt(10);
b := a;
Do it this way. Don't create obscure functions just so that you can cram it all onto a single line. The two lines above could not be clearer to read. Stop trying to force other languages into Pascal. They don't fit.
edited Jun 21 '16 at 6:12
answered Jun 21 '16 at 5:48
David Heffernan
515k348131205
515k348131205
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f37932462%2fis-it-possible-to-turn-a-statement-into-a-expression%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Did you look at the source to see how IfThen is implemented? (I'm not the close voter, BTW)
– Ken White
Jun 20 '16 at 22:27
1
@muschL: What exactly are you asking for ? This example shows a function which assigns to some variable and also returns the result, but this does not explain why you could not simply assign to the variable that you pass to the function and use that variable where you would have used the function return value. For more helpful responses, instead of showing a solution and asking a question which makes little sense on its own, explain what problem your solution is trying to solve, why you consider it inadequate and what you are trying to achieve that your solution currently does not.
– Deltics
Jun 20 '16 at 23:18
2
Delphi's IfThen is not equivalent to the C ternary operator. Try it with functions that have side effects on both sides and you'll see the difference. Your edit clarifies what you're asking, but I fail to see the point. Your mess with AssignAndReturn in your final example is horrific, and two separate lines of code to accomplish the same thing would be much more readable and maintainable. I fail to understand why people want to obfuscate or deface code by converting everything to look like C.
– Ken White
Jun 20 '16 at 23:54
1
In Pascal
:=
isn't an operator and doesn't return a l-value. This is by design. Your current solution is only possible way to do as you want.– Free Consulting
Jun 21 '16 at 0:38
3
Regarding the edit,
IfThen
is not equivalent to anif then else
statement. Only one branch of theif then else
is executed. All arguments to theIfThen
function are evaluated. Secondly, you already have an answer to your question. It is a simple "no". Thirdly, the reason people are criticising your proposed function is that it is a very bad idea to implement and use such a function. Do expect people to give you advice. Then it's up to you to decide how to react to that advice.– David Heffernan
Jun 21 '16 at 8:39