If and cond as special forms - scheme

Consider these two paragraphs from SICP:
This construct is called a case analysis, and there is a special form
in Lisp for notating such a case analysis. It is called cond (which
stands for “conditional”), and it is used as follows:
...
This uses the special form if, a restricted type of conditional that
can be used when there are precisely two cases in the case analysis.
What does type mean in this context (restricted type of conditional)? Does it mean:
"if" is a type of "cond"? Because the sentence states "there is a special form", so there is only one special form because "if" is one type of "cond".
Both "if" and "cond" are unrelated. They are both conditionals. If this is correct, why does this sentence say "there is a special form" like it is only one?

In " if [is] a restricted type of conditional", I believe "conditional" doesn't mean specifically cond; it means "conditional statement / expression", in general.
So there are two, cond and if. Each can be defined in terms of the other, so a given implementation may choose to have only one of them as a primitive, defining the other in terms of it; or the implementation can choose to have both of them as primitive special forms.
Special forms are handled specially by the interpreter (compiler) itself.
Macros also can be used for that. They won't be handled by the interpreter itself then, but rather by its macros-handling mechanism.
So if is a conditional; cond is a conditional; cond can have any number of clauses; if must have exactly two (or one or two, depending on the standard) clauses; all the rest is just English. :)

Related

Is there a Prolog name for moving a functor name in to an argument?

It is not uncommon to see data in Prolog written with a functor, e.g.
note("This is a note")
but Prolog can also process the data with the name moved to an argument, e.g.
(note,"This is a note")
When moving the data name from the functor into an argument, is there a name used to describe this process?
I have some code that will have the data converted as such and would like to include in the documentation a standard name to describe this change if it exist.
EDIT
The current specific reason for doing this is so I don't have to use =../2 and can also make comparison on many datum with anonymous variable, e.g.
(_,A,B,C)
or write more general predicates, e.g.
do(_)
do(_,A)
do(_,A,B)
instead of
do(note(A))
do(note(A,B))
do(note(A,B,C))
do(comment(A))
do(comment(A,B))
do(comment(A,B,C))
do(text(A))
do(text(A,B))
do(text(A,B,C))
EDIT
Below is a comment by #repeat with reasons not to do what is demonstrated in this question by changing a compound term note(A,B) into a comma list (A,B), as opposed to a regular list [A,B]. It is good advise but sometimes there are reasons for breaking such advise. I can not say at present for my current need if doing this in Prolog is one of those cases, but as the question asks, it would be nice to have a name for the process so that it can be searched for research.
#repeat You can edit this and add notes as it is all Creative Commons.
Actually, (note, "this is a note") is a term with functor , and arity 2 (first argument note, and second argument "this is a note").
You can see this issuing the following queries:
?- write_canonical(note("This is a note")).
note("This is a note")
?- write_canonical((note,"This is a note")).
','(note,"This is a note")
So what you are doing by "moving" the principal functor of a term of arity N to a term of arity N+1 with principal function , adding the previous functor name as the first argument and shifting the other arguments is some sort of generalization, though I don't know if there is a more suitable name for this.
You could see it as a restricted way to write an applicative encoding of a higher-order logic fragment into first order logic. An applicative encoding uses constants to represent functions and uses a binary function symbol app to express that f is applied to an argument list. For example, the applicative encoding of f(g(a),b) is app(f, [app(g,[a]),b ]). In your case, the ,/N operator plays this role but as you have probably noticed, without an argument list you need to know the number of arguments when you are matching against such a term.
An example where this encoding is used in a Prolog context is the higher-order automated theorem prover input format TPTP THF. They use an infix operator # to represent application. There, they also use the standard encoding which uses nested apps. The term representation is not as beautiful (the example term is written (f # (g # a))) # b) but it has the advantage that constants only have one representation. With the list encoding, you have to take into account that c = app(c, []).

Why are the names of predicates in scheme in the form of questions?

Racket is the first dialect of scheme I am learning, and I’m not that far in, however due to scheme’s minimal syntax, I believe it’s safe to assume that a question mark in variable names is not treated by the interpreter any differently than any other viable character.
With that run on sentence out of the way, why does scheme use the symbol “?” to denote a function that returns true or false (called a predicate)? For example, in racket, there is a built in function called number?. number? returns true when applied to any number (1, 5, -5, 2.7, etc), and false otherwise. I believe that number? is short for something along the lines of is_the_following_argument_a_number?. Assuming that is true, the expression (number? 5) translates into (is_the_following_argument_a_number? 5).
In english (the language this variable was written in), the predicate of “is the following argument a number?” can be found by first translating the question into its statement form by moving the verb: “the following argument is a number”, and then extracting the predicate: “is a number”. Now, I’m not the best at speaking languages as I am at programming languages, but I believe that is correct. Also, sorry if this is turning into an english question more than a scheme question.
What I am having trouble understanding is the fact that if the lisp community calls number? a predicate, why is the variable name not a predicate in english (I say that the variable name isn’t a predicate in english, not the type of function it is in scheme isn’t a predicate) I found what I thought the predicate of what I thought number? translated into, as being “is a number”, not the entire question “is the following argument a number?”, just the predicate. So, why does the lisp community choose to name predicates in scheme as questions in english? I believe that this is because the community mistakes the values of statements (true or false) for the answers to yes/no questions (yes or no (obviously)). Am I wrong to think this?
A predicate in computer science doesn't have anything to do with a predicate in language grammar. They both derive from having to do with thruth but otherwise they are unrelated concepts. A predicate in Scheme is a procedure that checks if something is true or not and in reality it can have any name. However since we can code information in the name it should contain to the point what it is about, which can be any word or even sentence delimited by hyphens, ending with question mark to indicate that it is indeed a predicate procedure. Both the name in the definition and the usage will stand out to the reader so that they know it without looking at the documentation or the implementation.
Scheme predicates in the very first Scheme report and the second looked like Common Lisp and the predicates in Scheme followed the same naming convention as Common Lisp has today. Old procedures that were in LISP 1.5 has the same name without the common p-ending while new introduced ones had it, like procp (called procedure? today). The reason for this is that Scheme run under MacLisp and borrowed all the dull stuff from it while it was lexical closures that were the magic of Scheme. Actually, it looked a lot looked like Common Lisp.
In the RRRS or R2RS they made all predicated end with ? and it worked with eq? and friends but the arithmetic predicates that used symbols, like <?, =?, <=?, etc, was not a success and were removed in the R3RS.
In a conditional we call the parts predicate, consequence and alternative:
(if (< a 0) ; predicate
(- a) ; consequent
a) ; alternative
Here a predicate is just an expression that either turns true or false. Actually all Scheme values are allowed and only #f is false. A predicate procedure is a procedure that always either returns #t or #f and it is as you are writing that number? check whether the argument is a number and string=? checks whether two arguments are strings that look the same. The pattern is very good and you can imagine what it does just by looking at the name being used while keeping the procedure names short. In speech we often do the same, like saying "coffee?" and getting either positive or negative response. It works most of the times and some times people need to spell it out that they are offering them a hot beverage whose name is coffee. In coding that means looking in the documentation or definition of a procedure.
There are other naming conventions in Scheme.
foo->bar is a procedure that takes an argument that is a foo type and it returns it as a bar type. number->string takes a number and makes a string representation of it. (number->string 5) ; ==> "5"
foo! may change the objects you pass it in order to do the job slightly faster than if it was named foo. set! and set-car! are examples.
*variable* are from CL but in Scheme you can be sure it is a global variable.
CONSTANT, +CONSTANT+, +constant+ are common naming for variables that are considered to be constants.
form* does something similar to what form does, but not quite. Special form let* does something similar to let but it binds one variable at a time.
The code works whether you follow these or not, but you are making it easier to read by using this convention and when you try to make a somparison procedure foo=? is just as easy to understand as are-these-two-foo-things-equal and foo? is just as easy as argument-is-a-foo.
Note that other programming languages also does this. In Java one write isFoo and equals so it's not spelled out there either.
It's just a programming convention. Predicates - meaning: those procedures that return true or false, are defined with a name that ends in a question mark. Similarly, Procedures that have side effects (e.g., that mutate state) are defined with a name that ends in exclamation mark.

Why is a braced-init-list not an expression?

While I am reading page93 $5.1.2 of the C++11 standard, during which it said it is ellegal for you to use the braced-init-list in this case:
auto x=[]{return {1,2}}; //error: a braced-init-list is not an expression
And I have found these two topics, one from the standard and the other from N3681 proposal.
Page397 $14.8.2.5:an initializer list argument causes the parameter to be considered a non-deduced context.
and $7.6.1.4:replacing the occurrences of auto with either a new invented type template parameter U or, if the initializer is a braced-init-list (8.5.4), with std::initializer_list.
While the N3691 proposal suggested "to change a brace-initialized auto to not deduce to an initializer list, and to ban brace-initialized auto for cases where the braced-initializer has more than one element. " and it said "returning a braced-list won't work as it's not an expression"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3681.html
However, I failed to find "Why is a braced-init-list not an expression?" It may have the same meaning of this topic:
Why can't we have automatically deduced return types?
but there's a little differences while he was trying to understand why the C++ commitee concluded this kind of grammar was worthless. So there must be a particular reason for this?Thank you very much.
Quoting from http://www.stroustrup.com/default-argument.pdf:
The reason that an initializer list isn’t an expression is simply that
we decided (correctly, IMO) not to allow initializer lists on the left
hand side of assignments, as operands of ++, etc. and further decided
(again correctly, IMO) to enforce that through the grammar.

Shorthand logic to prepend a variable in many languages

I'm interesting why the shorthand forms of the assignment operators only works in one way, that means appending the value of the variable.
Ex. (In Javascript):
x+=y x=x+y
x-=y x=x-y
x*=y x=x*y
x/=y x=x/y
x%=y x=x%y
Frequently I found situations where I need to prepend the variable:
Ex.
x=y+x
Suppose x and y are strings and you are concatenating.
I would like to have a syntax that allow something like:
x=+y
As I do with i++ or ++i incrementing number.
Is there some language that support this?
surely x=y+x is the same as y+=x
I'm puzzled as to why you would learn a new language just to save on 1 character!
However, I would suggest JQuery's .prepend() method
http://api.jquery.com/prepend/
There are languages that allow to define new operators and/or overload existing operators (see operator overloading).
But operators and the use of them should be unambiguous. In your example x=+y could be interpreted as x=y+x (as you denoted) but also as x=(+x) (+ as unary operation like negation operation in -1). This ambiguity can make using a language hard, especially when programmers want to make their code short and concise. That’s also why some languages don’t have syntactic sugar like pre/post increment/decrement operators (e.g. Python).

Unwanted evaluation in assignments in Mathematica: why it happens and how to debug it during the package-loading?

I am developing a (large) package which does not load properly anymore.
This happened after I changed a single line of code.
When I attempt to load the package (with Needs), the package starts loading and then one of the setdelayed definitions “comes alive” (ie. Is somehow evaluated), gets trapped in an error trapping routine loaded a few lines before and the package loading aborts.
The error trapping routine with abort is doing its job, except that it should not have been called in the first place, during the package loading phase.
The error message reveals that the wrong argument is in fact a pattern expression which I use on the lhs of a setdelayed definition a few lines later.
Something like this:
……Some code lines
Changed line of code
g[x_?NotGoodQ]:=(Message[g::nogood, x];Abort[])
……..some other code lines
g/: cccQ[g[x0_]]:=True
When I attempt to load the package, I get:
g::nogood: Argument x0_ is not good
As you see the passed argument is a pattern and it can only come from the code line above.
I tried to find the reason for this behavior, but I have been unsuccessful so far.
So I decided to use the powerful Workbench debugging tools .
I would like to see step by step (or with breakpoints) what happens when I load the package.
I am not yet too familiar with WB, but it seems that ,using Debug as…, the package is first loaded and then eventually debugged with breakpoints, ect.
My problem is that the package does not even load completely! And any breakpoint set before loading the package does not seem to be effective.
So…2 questions:
can anybody please explain why these code lines "come alive" during package loading? (there are no obvious syntax errors or code fragments left in the package as far as I can see)
can anybody please explain how (if) is possible to examine/debug
package code while being loaded in WB?
Thank you for any help.
Edit
In light of Leonid's answer and using his EvenQ example:
We can avoid using Holdpattern simply by definying upvalues for g BEFORE downvalues for g
notGoodQ[x_] := EvenQ[x];
Clear[g];
g /: cccQ[g[x0_]] := True
g[x_?notGoodQ] := (Message[g::nogood, x]; Abort[])
Now
?g
Global`g
cccQ[g[x0_]]^:=True
g[x_?notGoodQ]:=(Message[g::nogood,x];Abort[])
In[6]:= cccQ[g[1]]
Out[6]= True
while
In[7]:= cccQ[g[2]]
During evaluation of In[7]:= g::nogood: -- Message text not found -- (2)
Out[7]= $Aborted
So...general rule:
When writing a function g, first define upvalues for g, then define downvalues for g, otherwise use Holdpattern
Can you subscribe to this rule?
Leonid says that using Holdpattern might indicate improvable design. Besides the solution indicated above, how could one improve the design of the little code above or, better, in general when dealing with upvalues?
Thank you for your help
Leaving aside the WB (which is not really needed to answer your question) - the problem seems to have a straightforward answer based only on how expressions are evaluated during assignments. Here is an example:
In[1505]:=
notGoodQ[x_]:=True;
Clear[g];
g[x_?notGoodQ]:=(Message[g::nogood,x];Abort[])
In[1509]:= g/:cccQ[g[x0_]]:=True
During evaluation of In[1509]:= g::nogood: -- Message text not found -- (x0_)
Out[1509]= $Aborted
To make it work, I deliberately made a definition for notGoodQ to always return True. Now, why was g[x0_] evaluated during the assignment through TagSetDelayed? The answer is that, while TagSetDelayed (as well as SetDelayed) in an assignment h/:f[h[elem1,...,elemn]]:=... does not apply any rules that f may have, it will evaluate h[elem1,...,elem2], as well as f. Here is an example:
In[1513]:=
ClearAll[h,f];
h[___]:=Print["Evaluated"];
In[1515]:= h/:f[h[1,2]]:=3
During evaluation of In[1515]:= Evaluated
During evaluation of In[1515]:= TagSetDelayed::tagnf: Tag h not found in f[Null]. >>
Out[1515]= $Failed
The fact that TagSetDelayed is HoldAll does not mean that it does not evaluate its arguments - it only means that the arguments arrive to it unevaluated, and whether or not they will be evaluated depends on the semantics of TagSetDelayed (which I briefly described above). The same holds for SetDelayed, so the commonly used statement that it "does not evaluate its arguments" is not literally correct. A more correct statement is that it receives the arguments unevaluated and does evaluate them in a special way - not evaluate the r.h.s, while for l.h.s., evaluate head and elements but not apply rules for the head. To avoid that, you may wrap things in HoldPattern, like this:
Clear[g,notGoodQ];
notGoodQ[x_]:=EvenQ[x];
g[x_?notGoodQ]:=(Message[g::nogood,x];Abort[])
g/:cccQ[HoldPattern[g[x0_]]]:=True;
This goes through. Here is some usage:
In[1527]:= cccQ[g[1]]
Out[1527]= True
In[1528]:= cccQ[g[2]]
During evaluation of In[1528]:= g::nogood: -- Message text not found -- (2)
Out[1528]= $Aborted
Note however that the need for HoldPattern inside your left-hand side when making a definition is often a sign that the expression inside your head may also evaluate during the function call, which may break your code. Here is an example of what I mean:
In[1532]:=
ClearAll[f,h];
f[x_]:=x^2;
f/:h[HoldPattern[f[y_]]]:=y^4;
This code attempts to catch cases like h[f[something]], but it will obviously fail since f[something] will evaluate before the evaluation comes to h:
In[1535]:= h[f[5]]
Out[1535]= h[25]
For me, the need for HoldPattern on the l.h.s. is a sign that I need to reconsider my design.
EDIT
Regarding debugging during loading in WB, one thing you can do (IIRC, can not check right now) is to use good old print statements, the output of which will appear in the WB's console. Personally, I rarely feel a need for debugger for this purpose (debugging package when loading)
EDIT 2
In response to the edit in the question:
Regarding the order of definitions: yes, you can do this, and it solves this particular problem. But, generally, this isn't robust, and I would not consider it a good general method. It is hard to give a definite advice for a case at hand, since it is a bit out of its context, but it seems to me that the use of UpValues here is unjustified. If this is done for error - handling, there are other ways to do it without using UpValues.
Generally, UpValues are used most commonly to overload some function in a safe way, without adding any rule to the function being overloaded. One advice is to avoid associating UpValues with heads which also have DownValues and may evaluate -by doing this you start playing a game with evaluator, and will eventually lose. The safest is to attach UpValues to inert symbols (heads, containers), which often represent a "type" of objects on which you want to overload a given function.
Regarding my comment on the presence of HoldPattern indicating a bad design. There certainly are legitimate uses for HoldPattern, such as this (somewhat artificial) one:
In[25]:=
Clear[ff,a,b,c];
ff[HoldPattern[Plus[x__]]]:={x};
ff[a+b+c]
Out[27]= {a,b,c}
Here it is justified because in many cases Plus remains unevaluated, and is useful in its unevaluated form - since one can deduce that it represents a sum. We need HoldPattern here because of the way Plus is defined on a single argument, and because a pattern happens to be a single argument (even though it describes generally multiple arguments) during the definition. So, we use HoldPattern here to prevent treating the pattern as normal argument, but this is mostly different from the intended use cases for Plus. Whenever this is the case (we are sure that the definition will work all right for intended use cases), HoldPattern is fine. Note b.t.w., that this example is also fragile:
In[28]:= ff[Plus[a]]
Out[28]= ff[a]
The reason why it is still mostly OK is that normally we don't use Plus on a single argument.
But, there is a second group of cases, where the structure of usually supplied arguments is the same as the structure of patterns used for the definition. In this case, pattern evaluation during the assignment indicates that the same evaluation will happen with actual arguments during the function calls. Your usage falls into this category. My comment for a design flaw was for such cases - you can prevent the pattern from evaluating, but you will have to prevent the arguments from evaluating as well, to make this work. And pattern-matching against not completely evaluated expression is fragile. Also, the function should never assume some extra conditions (beyond what it can type-check) for the arguments.

Resources