difference between Composite Form & Special Form
In page 19 of Pratical Clojure by Luke VanderHart & Stuart Sierra, Chapter 2, there is a paragraph, Special forms definition : Special forms are a particular type of composite form. For most purposes, they are used very similarly to a function call. The difference is that the first form of a special form is not a function defined somewhere, but a special system form that’s built into Clojure. 1st question, Is the form word is a typo here? Isn't the word will be item? If not, is def a form? That means, this code contains 3 forms. :-s Cause later on, when the write was explaining an example, he used item. (def message "Hello, World!") Analyzing the first form, (def message "Hello, World!") , you see first that it is enclosed in parenthesis. Therefore, it is a list, and will be evaluated as a function application or a special form. There are three items in the list: def, message and "Hello, World!". The first item on the list, def, will be the function or special form that is called. In this case, it's a special form. But like a function, it takes two parameters—the var to define, and the value to which to bind it. Evaluating this form creates a var which establishes a binding of the value "Hello, World!" to the symbol message. 2nd question, Is a composite form is a special form only when, the first item of a list is something that is only predefined withing Clojure? If yes, then is it possible to create custom special form? Is then the custom composite form is gonna be called as a special form? Cause, according to the definition, my custom is not something built in clojure, it is defined somewhere else? EDIT: I guess the answer to my first question is no, its not a typo. def IS a form. cause later on the write said, The second form (println message) is also a list and this time it’s a normal function application. It has two component forms—each of them is a symbol That means, (println message) > the whole thing is a form, and every thing else(function arguments) that it holds is also a form. But, at the beginning the writer said, there are four basic varieties of forms. 1. Literal, 2. Symbol, 3. Composite form and 4. Special form. According to the definition of Symbols from the book, its not a symbol. Symbol Definition: Symbols are forms which resolve to a value. They may be thought of as roughly similar to variables, although this is not technically accurate since they are not actually variable in the same way variables in most languages are. In Clojure, symbols are used to identify function arguments, and globally or locally defined values. Symbols and their resolution are discussed in more detail in the following sections. Cause, writing def and pressing return key produces the following error message, In which category, def falls into? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: difference between Composite Form & Special Form
On Wed, May 25, 2011 at 10:15 PM, iamcreasy wrote:
> 1st question,
> Is the form word is a typo here? Isn't the word will be item? If not,
> is def a form? That means, this code contains 3 forms. :-s
Technically, anything that can be evaluated is a form. A composite
form is something like a literal list, vector, set, or map. The
literal list case is treated as an operator and arguments; the other
three just evaluate to vectors, sets, or maps, respectively, whose
members are the evaluations of the nested forms, so:
+ => the + function
(+ 1 2)=> 3
[+ 1 2]=> a vector of the + function, 1, and 2.
[(+ 1 2)] => [3]
#{(+ 1 2) 4} => #{3 4}
{:a (+ 1 2)} => {:a 3}
> 2nd question,
> Is a composite form is a special form only when, the first item of a
> list is something that is only predefined withing Clojure? If yes,
> then is it possible to create custom special form?
Sort of. You can create a macro with defmacro, which like a special
form controls the evaluation of its arguments instead of the arguments
being evaluated first and the function only getting the results.
Things like -> and defn are macros:
(-> 3
(+ 1)
(* 2))
adds 1 to 3, then doubles, yielding 8. This couldn't work with a
function, as it would get arguments 3, 1, and 2 as (+ 1) would
evaluate, first, to 1, and (* 2) to 2. It wouldn't know what to do
with 3, 1, or 2 -- whether to add 1 and then multiply by 2, or
subtract 1 and then add 2, or what. The macro, however, operates on
the *forms* and gets 3, (+ 1), and (* 2) and combines the first two
into (+ 3 1) and that and the third into (* (+ 3 1) 2) by inserting
each form into the next one after the operator and before everything
else.
(defn foo [a b] (+ (* a a) (* b b)))
also cannot be a normal function call. If it were there would be
several errors: foo undefined (most likely), also a and b undefined,
so the first argument foo could not be evaluated, nor could the second
[a b], nor could the third (+ (* a a) (* b b)). But instead it works
to generate a function definition. It's a macro that expands to a (def
...) form, in fact.
> But, at the beginning the writer said, there are four basic varieties
> of forms.
>
> 1. Literal,
> 2. Symbol,
> 3. Composite form and
> 4. Special form.
I'd say it's a bit more complicated than that. We have six things that
are evaluated somewhat differently:
1. nil, true, false, numbers, strings, regexps, keywords ... evaluate
to themselves.
2. symbols are looked up when evaluated to find a local or global var
value they evaluate to.
3. Set, vector, and map literals have subforms evaluated, then
evaluate to a set, vector, or map with the subforms replaced by their
evaluated values.
4. (foo bar baz), if foo is a special operator like def, is a special
form and is evaluated according to the built-in rules for that form.
5. (foo bar baz) with foo not a special operator: the subform foo is
looked up at compile time and if it's a macro, macro expansion is
performed. The transformed code is then evaluated per these rules.
6. (foo bar baz) with foo not a special operator or a macro. At
compile time, code is generated to evaluate foo, bar, and baz at
runtime and then apply foo as a function to the arguments bar and baz.
The latter three can, of course, have zero or more arguments, not just
two, and generalize appropriately.
Different things happen at compile and run time in each case:
Thing Compile Run
literal inserted into bytecoderecalled from memory
symbol var resolved, deref compiled var is deref'd
(def bar baz) bar var interned baz eval'd, bar set
(macro x y) macro is expanded expansion is eval'd
(func bar baz) fn-calling code compiled func called with args
For special forms other than def, the behavior varies; (if bar baz
quux) for example compiles to a conditional test and branch and at run
time bar is eval'd, then the test and possibly the branch occurs, and
either baz or quux is eval'd.
> According to the definition of Symbols from the book, its not a
> symbol.
'def is definitely a symbol. (No pun intended.) However (def ...) is
recognized as a special form by the compiler. Note that:
defsymbol
(def ...) special form
You can actually create variables named def and the like. If you
reference them in other than operator position, it works:
=> (defn def [x] (+ x 2))
#'user/def
=> (map def [1 2 3 4 5])
(3 4 5 6 7)
In operator position, though, you get the special form unless you
qualify the name:
=> (def quux 42)
#'user/quux
=> (user/def quux)
44
If you define it locally, you can't use it in operator position at
all, unless you rename it:
=> (let [def (fn [x y] (+ x y 2))
a def]
(println (def foo 42))
(println (a foo 42)))
#'user/foo
86
nil
The second let binding gives the local def another name, a, that can
be used to invoke it. It ends up usi
Re: difference between Composite Form & Special Form
On Wed, May 25, 2011 at 10:58 PM, Ken Wesson wrote:
> Different things happen at compile and run time in each case:
>
> Thing Compile Run
> literal inserted into bytecode recalled from memory
> symbol var resolved, deref compiled var is deref'd
> (def bar baz) bar var interned baz eval'd, bar set
> (macro x y) macro is expanded expansion is eval'd
> (func bar baz) fn-calling code compiled func called with args
Actually, I didn't include in there the literal set, vector, and map
case. There, the compiler emits code to evaluate the subforms and pass
them to the appropriate constructor to produce the set, vector, or
map; the runtime does the evaluation and construction. When the
collection literal has no non-self-evaluating nested forms, though,
it's possible the compiler optimizes this by simply emitting code to
retrieve the literal collection from memory somewhere.
There's also the subform evaluation matter:
Thing Subforms evaluated when?
[foo bar baz] at runtime, as arguments to vector constructor
#{foo bar} at runtime, as arguments to set constructor
{foo bar} at runtime, as arguments to map constructor
(def foo bar) foo isn't eval'd; bar eval'd to assign foo
(macro foo bar) at runtime, as decided by macro
(func foo bar) at runtime, before func called
Different special forms differ; e.g.
(if foo bar baz)
results in foo evaluated, and then either bar or baz depending on the
truthiness of whatever foo evaluated to.
Macros generally splice their argument forms into their expansion in
some manner, and the nature of that expansion determines what gets
called when. For example if -?> is defined to be a null-safe threading
macro, which acts like -> except that if any of the intermediate
results is nil it stops and evaluates to nil, then:
(-?> {:a 3}
(:b)
(+ 17))
will never evaluate the (+ something 17) clause because the result of
(:b {:a 3}) is nil.
The macro would expand this into something like:
(let [x {:a 3}]
(if x
(let [y (:b x)]
(if y
(+ y 17)
and then the rules for the special form (if ...) end up causing the (+
y 17) to not be evaluated.
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: difference between Composite Form & Special Form
> Sort of. You can create a macro with defmacro, which like a special
> form controls the evaluation of its arguments instead of the arguments
> being evaluated first and the function only getting the results.
> Things like -> and defn are macros:
That means, the difference of composite form and special form, is the
order / sequence of evaluation of arguments? right?
Composite form can be a function(list) or some other supported data
structures(Vector, map and set). Special form which looks a lot like a
funciton, is NOT a funciton / list / composite form at all.
This also means, what is written on the book about special form
"Special forms are a particular type of composite form. For most
purposes, they are used very similarly to
a function call. The difference is that the first form of a special
form is not a function defined
somewhere, but a special system form that’s built into Clojure."
is badly written or wrong, right?
Its not about being special form as a composite form, they are
different to begin with.
Its not about being 'built into clojure', its about how they work.
> 5. (foo bar baz) with foo not a special operator: the subform foo is
> looked up at compile time and if it's a macro, macro expansion is
> performed. The transformed code is then evaluated per these rules.
I didn't understand this one.Is it about user defined function?
> 6. (foo bar baz) with foo not a special operator or a macro. At
> compile time, code is generated to evaluate foo, bar, and baz at
> runtime and then apply foo as a function to the arguments bar and baz.
I didn't understand this point too. An example would help.
> (def bar baz) bar var interned baz eval'd, bar set
> (macro x y) macro is expanded expansion is eval'd
Arn't they same? def is written withing clojure and when needed its
expanded.
> 'def is definitely a symbol.
If def is a symbol then it should evaluated to somthing?like, when I
write 'print' and press return key, I get
#
but, in case of def, i get the following 'Error',
#
Isn't this concludes def is not a symbol cause its returning an error.
>From you explanation what i got that, built in macros are called
special form and I can also create my custom macros, which will be
called special forms. is it right?
Your second post is a little over my head :s
On May 26, 8:58 am, Ken Wesson wrote:
> On Wed, May 25, 2011 at 10:15 PM, iamcreasy wrote:
> > 1st question,
> > Is the form word is a typo here? Isn't the word will be item? If not,
> > is def a form? That means, this code contains 3 forms. :-s
>
> Technically, anything that can be evaluated is a form. A composite
> form is something like a literal list, vector, set, or map. The
> literal list case is treated as an operator and arguments; the other
> three just evaluate to vectors, sets, or maps, respectively, whose
> members are the evaluations of the nested forms, so:
>
> + => the + function
> (+ 1 2) => 3
> [+ 1 2] => a vector of the + function, 1, and 2.
> [(+ 1 2)] => [3]
> #{(+ 1 2) 4} => #{3 4}
> {:a (+ 1 2)} => {:a 3}
>
> > 2nd question,
> > Is a composite form is a special form only when, the first item of a
> > list is something that is only predefined withing Clojure? If yes,
> > then is it possible to create custom special form?
>
> Sort of. You can create a macro with defmacro, which like a special
> form controls the evaluation of its arguments instead of the arguments
> being evaluated first and the function only getting the results.
> Things like -> and defn are macros:
>
> (-> 3
> (+ 1)
> (* 2))
>
> adds 1 to 3, then doubles, yielding 8. This couldn't work with a
> function, as it would get arguments 3, 1, and 2 as (+ 1) would
> evaluate, first, to 1, and (* 2) to 2. It wouldn't know what to do
> with 3, 1, or 2 -- whether to add 1 and then multiply by 2, or
> subtract 1 and then add 2, or what. The macro, however, operates on
> the *forms* and gets 3, (+ 1), and (* 2) and combines the first two
> into (+ 3 1) and that and the third into (* (+ 3 1) 2) by inserting
> each form into the next one after the operator and before everything
> else.
>
> (defn foo [a b] (+ (* a a) (* b b)))
>
> also cannot be a normal function call. If it were there would be
> several errors: foo undefined (most likely), also a and b undefined,
> so the first argument foo could not be evaluated, nor could the second
> [a b], nor could the third (+ (* a a) (* b b)). But instead it works
> to generate a function definition. It's a macro that expands to a (def
> ...) form, in fact.
>
> > But, at the beginning the writer said, there are four basic varieties
> > of forms.
>
> > 1. Literal,
> > 2. Symbol,
> > 3. Composite form and
> > 4. Special form.
>
> I'd say it's a bit more complicated than that. We have six things that
> are evaluated somewhat differently:
>
> 1. nil, true, false, numbers, strings, regexps, keywords ... evaluate
> to themselves.
>
Re: difference between Composite Form & Special Form
> Sort of. You can create a macro with defmacro, which like a special
> form controls the evaluation of its arguments instead of the arguments
> being evaluated first and the function only getting the results.
> Things like -> and defn are macros:
That means, the difference of composite form and special form, is the
order / sequence of evaluation of arguments? right?
Composite form can be a function(list) or some other supported data
structures(Vector, map and set). Special form which looks a lot like a
funciton, is NOT a funciton / list / composite form at all.
This also means, what is written on the book about special form
"Special forms are a particular type of composite form. For most
purposes, they are used very similarly to
a function call. The difference is that the first form of a special
form is not a function defined
somewhere, but a special system form that’s built into Clojure."
is badly written or wrong, right?
Its not about being special form as a composite form, they are
different to begin with.
Its not about being 'built into clojure', its about how they work.
> 5. (foo bar baz) with foo not a special operator: the subform foo is
> looked up at compile time and if it's a macro, macro expansion is
> performed. The transformed code is then evaluated per these rules.
I didn't understand this one.Is it about user defined function?
> 6. (foo bar baz) with foo not a special operator or a macro. At
> compile time, code is generated to evaluate foo, bar, and baz at
> runtime and then apply foo as a function to the arguments bar and baz.
I didn't understand this point too. An example would help.
> (def bar baz) bar var interned baz eval'd, bar set
> (macro x y) macro is expanded expansion is eval'd
Arn't they same? def is written withing clojure and when needed its
expanded.
> 'def is definitely a symbol.
If def is a symbol then it should evaluated to somthing?like, when I
write 'print' and press return key, I get
#
but, in case of def, i get the following 'Error',
#
Isn't this concludes def is not a symbol cause its returning an error.
>From you explanation what i got that, built in macros are called
special form and I can also create my custom macros, which will be
called special forms. is it right?
Your second post is a little over my head :s
On May 26, 8:58 am, Ken Wesson wrote:
> On Wed, May 25, 2011 at 10:15 PM, iamcreasy wrote:
> > 1st question,
> > Is the form word is a typo here? Isn't the word will be item? If not,
> > is def a form? That means, this code contains 3 forms. :-s
>
> Technically, anything that can be evaluated is a form. A composite
> form is something like a literal list, vector, set, or map. The
> literal list case is treated as an operator and arguments; the other
> three just evaluate to vectors, sets, or maps, respectively, whose
> members are the evaluations of the nested forms, so:
>
> + => the + function
> (+ 1 2) => 3
> [+ 1 2] => a vector of the + function, 1, and 2.
> [(+ 1 2)] => [3]
> #{(+ 1 2) 4} => #{3 4}
> {:a (+ 1 2)} => {:a 3}
>
> > 2nd question,
> > Is a composite form is a special form only when, the first item of a
> > list is something that is only predefined withing Clojure? If yes,
> > then is it possible to create custom special form?
>
> Sort of. You can create a macro with defmacro, which like a special
> form controls the evaluation of its arguments instead of the arguments
> being evaluated first and the function only getting the results.
> Things like -> and defn are macros:
>
> (-> 3
> (+ 1)
> (* 2))
>
> adds 1 to 3, then doubles, yielding 8. This couldn't work with a
> function, as it would get arguments 3, 1, and 2 as (+ 1) would
> evaluate, first, to 1, and (* 2) to 2. It wouldn't know what to do
> with 3, 1, or 2 -- whether to add 1 and then multiply by 2, or
> subtract 1 and then add 2, or what. The macro, however, operates on
> the *forms* and gets 3, (+ 1), and (* 2) and combines the first two
> into (+ 3 1) and that and the third into (* (+ 3 1) 2) by inserting
> each form into the next one after the operator and before everything
> else.
>
> (defn foo [a b] (+ (* a a) (* b b)))
>
> also cannot be a normal function call. If it were there would be
> several errors: foo undefined (most likely), also a and b undefined,
> so the first argument foo could not be evaluated, nor could the second
> [a b], nor could the third (+ (* a a) (* b b)). But instead it works
> to generate a function definition. It's a macro that expands to a (def
> ...) form, in fact.
>
> > But, at the beginning the writer said, there are four basic varieties
> > of forms.
>
> > 1. Literal,
> > 2. Symbol,
> > 3. Composite form and
> > 4. Special form.
>
> I'd say it's a bit more complicated than that. We have six things that
> are evaluated somewhat differently:
>
> 1. nil, true, false, numbers, strings, regexps, keywords ... evaluate
> to themselves.
>
Re: difference between Composite Form & Special Form
On Mon, May 30, 2011 at 12:47 AM, iamcreasy wrote: >> Sort of. You can create a macro with defmacro, which like a special >> form controls the evaluation of its arguments instead of the arguments >> being evaluated first and the function only getting the results. >> Things like -> and defn are macros: > > That means, the difference of composite form and special form, is the > order / sequence of evaluation of arguments? right? > Composite form can be a function(list) or some other supported data > structures(Vector, map and set). Special form which looks a lot like a > funciton, is NOT a funciton / list / composite form at all. I'd use "composite form" for anything that, in source code, is not an atom -- a list, vector, set, or map. Others may use it differently. The book you have seems to use it to mean just lists. > This also means, what is written on the book about special form > "Special forms are a particular type of composite form. For most > purposes, they are used very similarly to > a function call. The difference is that the first form of a special > form is not a function defined > somewhere, but a special system form that’s built into Clojure." > > is badly written or wrong, right? No. > Its not about being special form as a composite form, they are > different to begin with. Not really. > Its not about being 'built into clojure', its about how they work. It's both. >> 5. (foo bar baz) with foo not a special operator: the subform foo is >> looked up at compile time and if it's a macro, macro expansion is >> performed. The transformed code is then evaluated per these rules. > > I didn't understand this one.Is it about user defined function? No, macros. >> 6. (foo bar baz) with foo not a special operator or a macro. At >> compile time, code is generated to evaluate foo, bar, and baz at >> runtime and then apply foo as a function to the arguments bar and baz. > > I didn't understand this point too. An example would help. (def foo 42) Since 'def is a special operator, this is a special form and it has special evaluation rules. It ends up interning a Var named 'foo in the current namespace with the value 42. (defn bar [] 42) Since 'defn is not a special operator, the compiler checks the namespace for any Var visible in it named 'defn. It finds that 'clojure.core/defn is referred, and uses that. The object in that Var proves to be a macro, so the compiler expands it by calling it as a function with the rest of the form, unevaluated, as arguments. This produces something resembling (def bar (fn bar [] 42)) and this is a 'def special form, which ends up interning a Var named 'bar in the current namespace whose value is a function object which, when called with no arguments, returns the number 42. (bar) Since 'bar is not a special operator, the compiler checks the namespace for any Var visible in it named 'bar. It finds that the current namespace itself contains a Var named 'bar and uses that. The object in that Var proves to be a function, so the compiler converts this form into bytecode that calls the function. At runtime, when this executes, the function returns the number 42. >> (def bar baz) bar var interned baz eval'd, bar set >> (macro x y) macro is expanded expansion is eval'd > > Arn't they same? def is written withing clojure and when needed its > expanded. Not really. Special forms have special evaluation rules. The bytecode emitted can, in theory, be anything, and things can be done at compile time. In the case of def, a Var is interned as soon as the compiler even sees the form. If you didn't already have def you might be able to recreate it as a macro using some interop calls on *ns* to intern a Var. On the other hand if you didn't already have try you would not be able to recreate that with a macro at all. No combination of functions and macros compiles to bytecode that includes an exception handler unless it contains the try special form after all macroexpansion. >> 'def is definitely a symbol. > > If def is a symbol then it should evaluated to somthing?like, when I > write 'print' and press return key, I get > > # > > but, in case of def, i get the following 'Error', > > # in this context (NO_SOURCE_FILE:0)> > > Isn't this concludes def is not a symbol cause its returning an error. No; 'def is a symbol but it's not bound to anything in the current namespace so you get the "unable to resolve" message. Meanwhile, 'print is bound to a function object from clojure.core. When you type print at the REPL it evaluates to the function object, which prints the way you saw. And if you quote, typing either 'def or 'print, you get the symbol itself back. If you (def def 42) and evaluate def you'll get 42 instead of the "unable to resolve" message. But (def ...) won't throw a "cannot cast Integer to IFn" message the way (42 ...) would, because the symbol 'def in operator position is always treated as a special operator rather than looked up. This
