Styjun

I know there is macro-function, explained here, which allows you to check, but is it also possible in simply reading lisp source to sometimes infer of what you're looking at "that must be a macro"? (assuming of course you have never seen the function/macro before).

I'm fairly sure the answer is yes, but as this seems so fundamental, I thought worth asking, especially because any nuances on this may be valuable & interesting to know about.

In Paul Graham's ANSI Common Lisp, p70, he is describing how to use defstruct.

When I see (defstruct point x y), were I to know absolutely nothing about what defstruct was, this could just as well be a function.

But when I see

(defstruct polemic
 (subject "foo")
 (effect "bar"))

I know that must be a macro because (let's assume), I also know that subject and effect are undefined functions. (I know that because they error with undefined function when called 'at the top level'(?)) (if that's the right term).

If the two list arguments to defstruct above were quoted, it would not be so simple. Because they're not quoted, it must be a macro.

Is it as simple as that?

I've changed the field names slightly from those used on the book to make this question clearer.

Finally, Graham writes:

"We can specify default values for structure fields by enclosing the field name and a default expression in a list in the original definition"

What I'm noticing is that that's true but it is not a (quoted) list. Would any readers of this post have phrased the above sentence at all differently (given that macros haven't been introduced in the book yet (though I have a basic awareness of what they are)).

My feeling is it's not a "data list" those default expressions are enclosed in. (apologies for bad terminology) - seeking how rightly to conceptualise here.

In general, you're right: if there's some nesting inside the call and you are sure that the car's of the nested lists aren't functions - it's a macro.

Also, almost always, def-something and with-something are macros.

But there's no guarantee. The question is, what are you trying to accomplish? Some code walking/transformation or external processing (like in an editor). For the latter, you should keep in mind that full control is possible only if you perform code evaluation, although heuristics (like in Emacs) can take you pretty far. Or you just want to develop your intuition for faster code reading...

There is a set of conventions that identify quite cleary what forms are supposed to be macros, simply by mimicking the syntax of existing macros or special operators of CL.
For example, the following is a mix of various imaginary macros, but even without knowing their definition, the code shouldn't be too hard to figure out:

(defun/typed example ((id (integer 0 10)))
 (with-connection (connection (connect id))
 (do-events (event connection)
 (event-case event
 (:quit (&optional code) (return code))))))

The usual advice about macros is to avoid them if possible, so if you spot something that doesn't make sense as a lisp expression, it probably is, or is enclosed in, a macro.

(defstruct point x y)

[...] were I to know absolutely nothing about what defstruct was, this could just as well be a function.

There are various hints that this is not a function. First of all, the name starts with def. Then, if defstruct was a function, then point, x and y would all be evaluated before calling the function, and that means the code would be relying on global variables, even though they are not wearing earmuffs (e.g. *point*, *x*, *y*), and you probably won't find any definition for them in the preceding forms (or later in the same compilation unit). Also, if it was a function, the result would be discarded directly since it is not used (this is a toplevel form). That only indicates the probable presence of side-effects, but still, this would be unusual.
A top-level function with side-effects would look like this instead, with quoted data:

(register-struct 'point '(x y))

Finally, there are cases where you cannot easily guess if you are using a macro or a function:

(my-get object :slot)

This could be a function call, or you could have a macro that turns the above to (aref object 0) (assuming :slot is the zeroth slot in object, because all your objects are assumed to be of a certain custom type backed by a vector). You could also have compiler macros. In case of doubt, try to macroexpand it and look at the documentation.