In the PHP code
if(a() && b())
when the first operand evaluates to false, b() will not be evaluated.
Similarly, in
if (a() || b())
when the first operand evaluates to true, b() will not be evaluated..
Is this true for all languages, like Java, C#, etc?
This is the test code we used.
<?php
function a(){
echo 'a';
return false;
}
function b(){
echo 'b';
return true;
}
if(a() && b()){
echo 'c';
}
?>
This is called short-circuit evaluation.
It is generally true for languages derived from C (C, C++, Java, C#) but not true for all languages.
For example, VB6 does not do this, nor was it done in early versions of VB.NET. VB8 (in Visual studio 2005) introduced the AndAlso and OrElse operators for this purpose.
Also, from comments, it seems that csh performs short-circuit evaluation from right to left, to make matters even more confusing.
It should also be pointed out that short-circuit evaluation (or lack of) has its dangers to be aware of. For example, if the second operand is a function that has any side effects, then the code may not perform exactly as the programmer intended.
It's not true for VB6.
In VB.net you have to use "AndAlso" instead of "And" if you want it to skip evaluating the second expression.
Is this true for ALL languages, like JAVA, C#, etc?
In C# this is only true for the short-circuiting operators '||' and '&&'; if you just use '|' or '&' it will evaluate both sides every time.
It's called short-circuit evaluation and most languages do this. In some languages there exists operators that don't do this.
The original version of Pascal did not, which caused lots of grief. Modern Pascals, such as Delphi work the same way as C et al.
Ada has special short-circuited forms of conditionals:
and then
or else
used like this:
if p.next /= null and then p.next.name = 'foo'
if x = 0 or else 1/x = y
In some ways it's kind of nice because you can deduce that the programmer knew the expression needed to be short-circuited and that the conditional is not working by accident.
It is true for languages that are "children" of the C : PHP, Java, C++, C#, ... or in the same "inspiration", like Perl.
But it is not true for VB (at least before .NET, which introduced new keywords for that).
(And that's really disturbing the first you work with VB ^^ )
Microsoft VBScript (often used in conjunction with 'Classic' ASP) had no short-circuit evaluation for boolean operators, instead it uses bitwise evaluation. Which is one of the many reasons it is possibly the worst language ever!
"What's going on is that VBScript is
not logical. VBScript is bitwise. All
the so-called logical operators work
on numbers, not on Boolean values!
Not, And, Or, XOr, Eqv and Imp all
convert their arguments to four-byte
integers, do the logical operation on
each pair of bits in the integers, and
return the result. If True is -1 and
False is 0 then everything works out,
because -1 has all its bits turned on
and 0 has all its bits turned off. But
if other numbers get in there, all
bets are off".
Taken from this blog. by Eric Lippert.
In Delphi it's a compiler option.
In standard FORTRAN or Fortran, the operands of a boolean expression can be evaluated in any order. Incomplete evaluation is permitted, but implementation defined.
This allows optimisation of boolean expressions that would not be permitted if strict Left-To-Right ordering was enforced. Expressions which require strict ordering must be decomposed into seperate conditionals, or implementation-dependent assumptions can be made.
Since decomposition is used to enforce ordering, it follows that seperate IF statements can not always be optimised into a single expression. However, short-circuit evaluation is explicit with decomposition, and this is never worse than languages which enforce strict left-to-right ordering to allow lazy evaluation.
Languages wich are derived from FORTRAN (Fortran, BASIC, VBn), and languages which were designed to achieve FORTRAN-like efficiency (Pascal, Ada) initially followed the FORTRAN example of allowing out-of-order evaluation.
This is true for Java as well but the operators |, & etc will evaluate both sides.
In Erlang, the and and or operators do not do short-circuit evaluation; you have to use orelse and andalso operators if you want short-circuiting behavior.
Most languages (all that I've seen) use short circuit evaluation on CONDITIONAL operators such as && and ||. They will stop evaluating as soon as one of the conditions has satisfied the requirement. (The first false on &&. The first true on ||)
All BINARY operators such as & and |, are processed. (Original)
All BITWISE operators such as & and |, are processed. (Edit: 5/10/17)
This is called short-circuit evaluation and it is common for all of the languages that I have ever worked in (C, C++, C#, Java, Smalltalk, Javascript, Lisp) except for VB, VB.NET and Fortran.
It's actually a pretty useful feature. Without short-circuiting you wouldn't be able to do this:
if (a != null && a.isBlank())
Without short-circuiting you would have to have nested if statements because the second part would throw an error if a was null.
Coldfusion will natively do short-circut evaluation. I am sure all CF developers have written:
<cfif isdefined("somevariable") and somevariable eq something>
//do logic
</cfif>
MATLAB is one language that distinguishes between "standard" logical operators and short-circuit operators:
& (AND operator) and | (OR operator) can operate on arrays in an element-wise fashion.
&& and || are short-circuit versions for which the second operand is evaluated only when the result is not fully determined by the first operand. These can only operate on scalars, not arrays.
Other answers have given good examples of languages with and without short circuit evaluation so I won't repeat them.
Just one interesting point to add: Lisps such as Clojure have boolean short circuit evaluation, but in addition you can quite trivially define any operator you like with short circuit evaluation through the use of macros.
Example of a short-circuiting "nand" operation in Clojure:
(defmacro nand
([x]
`(not ~x))
([x & xs]
`(let [nand# (not ~x)]
(if nand#
true ; short circuit if we can prove the nand is true
(nand ~#xs))))) ; continue with the other expressions otherwise
(nand true true)
=> false
(nand false (println "Expression with a side effect!"))
=> true
Related
Are there any macros that:
Cannot be expressed as a equivalent function, or:
Are difficult to express as a equivalent function, or:
Are significantly worse in terms of performance than equivalent function?
Can you give an example of such a macro (and function)?
My question refers specifically to Lisp's macros and functions, but you may treat this question more generally. I'm particularly interested in recursive macros.
Edit:
I should've been more specific. When I asked the above question, I kept in mind specific context of my Lisp project, which is kind of mathematical symbolic programming calculator.
I was wondering if there is good reason to use macro for any of the mathematical operations, like:
analytical integration,
analytical differentiation,
polynomial operations,
computing Taylor series for given function,
computing trigonometric identities,
and so on...
For some reason I need to use a few recursive macros for this project. So, if I can reformulate my question:
Can you give examples of smart use of [recursive] macros in a symbolic calculation?
Are there any macros that:
Cannot be expressed as a equivalent function, or:
Are difficult to express as a equivalent function, or:
Are significantly worse in terms of performance than equivalent function?
The answer is never quite this simple. It's typically "yes and no". As I see it, there are two big advantages of macros: syntactic sugar delayed evaluation. For instance, macros like with-open-file, which lets you write:
(with-open-file (var "some-filename")
; operations with var
)
is pretty much just syntactic sugar for
(let ((x (open ...)))
(unwind-protect
(funcall (lambda (var)
; operations with var
)
x)
; cleanup forms
))
That's sort of a mix of delayed evaluation and syntactic sugar, depending on how you look at it. It's delayed evaluation, in that all the operations with var are wrapped up into a lambda function. It's also syntactic sugar, because you could obviously abstract the above into:
(defun call-with-open-file (open-args function)
(let ((x (apply 'open open-args)))
(unwind-protect (funcall function x)
; cleanup forms
)))
and then with-open-file is just syntactic sugar:
(defmacro with-open-file ((var &rest open-args) &body body)
`(call-with-open-file (list ,#open-args)
(lambda (,var) ,#body)))
That's a typical case that exhibits both delayed evaluation (of the body forms) and syntactic sugar around a functional interface. You can typically always do that. E.g., with if, you could write a functional interface:
(defun %if (condition then &optional (else (constantly nil)))
`(funcall (cond (condition then) (t else))))
Then if can be implemented as a macro:
(defmacro if (condition then &optional else)
`(%if condition (lambda () ,then) (lambda () ,else)))
if and other conditional forms are a bit unique, in this sense, though, because the implementation ultimately has to provide you some conditional operation. That operator typically isn't a macro, though, but a special form.
What about other special macros like loop, that define domain specific languages? You can do those too, but you pretty much would just end up having the function accept the "body" of the macro version and interpret it at runtime. E.g., you could do
(defun %loop (&rest loop-body)
; interpret body
)
but that's obviously going to be a big performance hit.
So, I'd posit that there are no macros that don't have a semantic equivalent, but these will require somewhat different arguments. Some of those semantically equivalent functions will be difficult to expression, and some of them (e.g., when passing anonymous functions around) will certainly have significantly worse performance.
I think your question is not well posed since it is based on the ambiguous use of the term “equivalent”. At a first sight, it seems that you intend “equivalent” as: “calculating the same value” (and this is confirmed by your third question about performance).
But they are not equivalent at all, because functions produce (or calculate) values, while macros produce (or calculate) programs! (and when you understand this, you will understand that a macro actually is a function, a function from s-expressions (the “quoted arguments”) to s-expressions).
So, I think that the answer to your questions should be given in these terms:
1) If you stretch the meaning of equivalence as “when the result of a macro, (i.e. a program), is further evaluated by the system”, than an answer like that of Joshua Taylor is to be taken into consideration;
2) If you are asking about macros and functions per se, they are not equivalent at all.
And concerning their use in the task you are addressing: macros can be really useful in defining particular control structures, or specialized ways of performing computation, like in DSL (Domain Specific Languages), but my advice is to use them only when you think that your problem could be solved in an easier way by adding to the usual tools (i.e. predefined functions, special forms and macros) new powerful tools, and when you have experience in writing complex macros (to practice this, see for instance the book of Paul Graham On Lisp).
Are there any macros that cannot be expressed as a function?
Yes; all macros in any expertly written Lisp program!
There are sometimes macros that can be replaced by functions, if you radically change or augment underlying language implementation.
For instance, a macro might be simulating something that otherwise requires continuations in a Lisp dialect that doesn't have them. Or it might be doing something that looks like non-strict evaluation, over a strict language. Something can can be done just with functions in a call-by-name language can be expressed with macros over pure call-by-value.
Macros go away when they are expanded; all that is left is special operators and functions. What functions can or cannot do depends on the available special operators. For instance without a operators to capture a continuation, a function cannot abandon its evaluation in such a way that it can be later restarted.
Therefore it is a false dichotomy to think about the power as being divided between macros and functions, while ignoring special operators.
A given problem can be solved by a combination of functions and special operators. If it requires certain special operators, then we cannot say that
the problem is solved by functions alone.
Macros can be used in such a way that they hide the use of special operators. Macros which conceal the essential use of special operators cannot be rewritten as functions.
For instance, a macro that provides syntactic sugar over a lambda operator cannot be written as a function. The macro's essential functionality depends on the fact that it expands to a lambda operator which captures a closure in the original lexical environment where the macro call occurs.
When Lisp language designers extend a dialect with new core functionality, they do so by adding new special forms. Macros are added at the same time to make the forms easier to use. For instance, I recently added delimited continuations to a Lisp dialect. The underlying API is not the easiest thing to use for certain simple tasks, so I also provided macros which provide an easy-to-use "generator" abstraction. Needless to say, these generator macros cannot be implemented with functions. Not only that, those macros cannot be implemented at all without the delimited continuation support; all they do is write code that depends on using these new special forms, and those special forms are implemented by hacks deep the language core which do nasty things like copying sections of the run-time stack to the heap, and back to a different area of the stack.
Now in a purely interpretive Lisp that runs programs by evaluating raw source code, you can have a form of function which is as powerful as a macro (in fact, more so). This is a function which, when it is called at run-time, receives its argument expressions unevaluated, together with the run-time environment needed to evaluate them. Essentially, such a function, though written by the user, acts as an "interpreter plugin", called upon to interpret code in an arbitrary way. In historic Lisp terminology, this kind of function is called a "fexpr".
The relationship between macros and fexprs is that macros are to fexprs what compilers are to interpreters. If you have a dialect with fexprs, then there is no reason to use macros if the only requirement is to support some syntax with some semantics, without caring about performance. A macro may be able to do the same thing by compiling to a more efficient translation. Even though the dialect is purely interpretive, it's nevertheless faster to have the interpreter run some macro-generated code, than for the interpreter to interpret a function, which itself interprets code.
But, of course, though fexprs are functions, they are not ordinary functions; ordinary functions receive evaluated arguments and no environment. So that just changes the question to: are there essential fexprs that cannot be replaced by ordinary functions?
The answer is: yes, any fexprs in an expertly written program ...
Any Lisp macro which does not evaluate ("twice", since it is a macro) its arguments cannot be expressed as a function, since function application is done on evaluated arguments. For example you could define a macro my-if which behaves exactly like if (and if cannot be a function)
C.Queinnec's book Lisp In Small Pieces explains that in great detail (and has several chapters about macros). I strongly recommend to read it (since answering your too broad question may require an entire book, not a paragraph).
If a macro expands one of its arguments several times, it might be slower than the equivalent function (because some sub-computations could be done twice if expanded twice).
(of course, the answer to all your questions can be yes; I leave up to you how to find some examples).
PS. BTW, this is even true in C....
I have learned (from a SML book) that functions in SML always takes just one argument: a tuple. A function that takes multiple arguments is just a function that takes one tuple as argument, implemented with a tuple binding in function binding. I understand this point.
But after this, the book says something that I don't understand:
this point makes SML language flexible and elegant design, and you can do something useful that you cannot do in Java.
Why does this design make the language Flexible? What is the text referring to, that SML can but java cannot?
Using tuples instead of multiple arguments adds flexibility in the sense that higher-order functions can work with functions of any "arity". For example to create the list [f x, f y, f z], you can use the higher-order function map like this:
map f [x, y, z]
That's easy enough - you can do that in any language. But now let's consider the case where f actually needs two arguments. If f were a true binary function (supposing SML had such functions), we'd need a different version of map that can work with binary functions instead of unary functions (and if we'd want to use a 3-ary functions, we'd need a version for those as well). However using tuples we can just write it like this:
map f [(x,a), (y,b), (z,c)]
This will create the list [f (x,a), f (y,b), f (z,c)].
PS: It's not really true that all functions that need multiple arguments take tuples in SML. Often functions use currying, not tuples, to represent multiple arguments, but I suppose your book hasn't gotten to currying yet. Curried functions can't be used in the same way as described above, so they're not as general in that sense.
Actually I don't think you really understand this at all.
First of all, functions in SML doesn't take a tuple as argument, they can take anything as argument. It is just sometimes convenient to use tuples as a means of passing multiple arguments. For example a function may take a record as argument, an integer, a string or it may even take another function as argument. One could also say that it can take "no arguments" in the sense that it may take unit as the argument.
If I understand your statement correctly about functions that takes "multiple arguments" you are talking about currying. For example
fun add x y = x + y
In SML, currying is implemented as a derived form (syntactic sugar). See this answer for an elaboration on how this actually works. In summary there is only anonymous functions in SML, however we can bind them to names such that they may "referred to"/used later.
Behold, ramblings about to start.
Before talking about flexibility of anything, I think it would be in order to state how I think of it. I quite like this definition of flexibility of programming languages: "[...] the unexpectedly many ways in which utterings in the language can be used"
In the case of SML, a small and simple core language has been chosen. This makes implementing compilers and interpreters easy. The flexibility comes in the form that many features of the SML language has been implemented using these core language features such as anonymous functions, pattern matching and the fact that SML has higher-order functions.
Examples of this is currying, case expressions, record selectors, if-the-else expressions, expression sequences.
I would say that this makes the SML core language very flexible and frankly quite elegant.
I'm not quite sure where the author was going regarding what SML can do, that java can't (in this context). However I'm quite sure that the author might be a bit biased, as you can do anything in java as well. However it might take immensely amounts of coding :)
In C++ one can overload the == and != operators for user types, but the language doesn't care how you do it. You can overload both to return true no matter what, so !(a==b) and (a!=b) don't necessarily have to evaluate to the same thing. How many other languages have a situation where ¬(a = b) and (a ≠ b) can be different? Is it a common thing?
It's not just an issue of overloads, but of strange corner cases even for primitive types. NaN in C and C++ doesn't compare equal to anything, including NaN. It is true that NaN != NaN in C, but maybe there are similar cases in other languages that cause ¬(a = b) and (a ≠ b) to be different?
Guy L. Steele famously said
...the ability to define your own operator functions means that a simple statement such as x=a+b; in an inner loop might involve the sending of e-mail to Afghanistan.
And as corsiKa says, just because you can do it, doesn't make it a good idea.
I know for a fact that Python and Ruby can and Java and PHP can not. (In Java == determines if two objects are the same thing in memory, not just semantically equivalent values. In PHP...never mind.) I'd also imagine that Lisp and JS can and C can not, but that's a bit more speculative.
It's nothing unusual to be able to overload operators. It is very rare for !(a==b) and (a!=b) to have different results though.
We all know that the logical && operator short circuits if the left operand is false, because we know that if one operand is false, then the result is also false.
Why doesn't the bitwise & operator also short-circuit? If the left operand is 0, then we know that the result is also 0. Every language I've tested this in (C, Javascript, C#) evaluates both operands instead of stopping after the first.
Is there any reason why it would be a bad idea the let the & operator short-circuit? If not, why don't most languages make it short-cicuit? It seems like an obvious optimization.
I'd guess it's because a bitwise and in the source language typically gets translated fairly directly to a bitwise and instruction to be executed by the processor. That, in turn, is implemented as a group of the proper number of and gates in the hardware.
I don't see this as optimizing much of anything in most cases. Evaluating the second operand will normally cost less than testing to see whether you should evaluate it.
Short-circuiting is not an optimization device. It is a control flow device. If you fail to short-circuit p != NULL && *p != 0, you will not get a marginally slower program, you will get a crashing program.
This kind of short-circuiting almost never makes sense for bitwise operators, and is more expensive than normal non-short-circuiting operator.
Bitwise operations are usually so cheap that the check would make the operation twice as long or more, whereas the gain from short-circuiting a logical operator is potentially very great.
If the compiler has to emit a check for both operands of & I guess that you it'll be much slower in any NORMAL condition.
For the same reason that * does not short-circuit if the first operand is 0 -- it would be an obscure special case and adding special runtime tests for it would make all multiplies slower.
When the operands are not constants, short circuiting is more expensive than not short circuiting, so you don't want to do it unless the programmer explicitly requests it. So you really want to have clean and simple rules as to when it occurs.
My questions is, "Why would a language designer consider allowing comparison between different data types?". Also, does this make more sense in a functional language?
For example, in erlang one can perform the following comparisons:
%% Tuples are greater than numbers
999999 < {1,2}.
true
%% Lists are greater than tuples
{90000} < [1].
true
%% Atoms are greater than numbers
1 < false.
true
In python 2.x as well,
p = lambda x,y: x+y
p > (1)
True
p < (1)
False
p == (1)
False
Though looks like the python community decided this wasn't a good idea after all:
objects of different types always
compare unequal, and are ordered
consistently but arbitrarily.
[...]
This unusual definition of comparison
was used to simplify the definition of
operations like sorting and the in and
not in operators.
source
From the Python 3 release note:
The ordering comparison operators (<,
<=, >=, >) raise a TypeError exception
when the operands don’t have a
meaningful natural ordering. Thus,
expressions like 1 < '', 0 > None or
len <= len are no longer valid, and
e.g. None < None raises TypeError
instead of returning False. A
corollary is that sorting a
heterogeneous list no longer makes
sense – all the elements must be
comparable to each other.
source
This kind of explains why, but I was wondering if there are other reasons to allow this, particularly in functional languages.
In dynamic languages it makes a certain amount of sense, as it's nice to be able to sort heterogeneous lists and build heterogeneous trees. And I think I would say that it's not so much functional languages where it's dubious as it is strongly typed languages, for obvious reasons.