I don't understand the question? In particular, it feels out of place? The common claim is that code is data. This does not necessarily imply that data is code.
That said, amusingly, `(1 2 3)` can easily be considered code if you are able to evaluate permutation notation. No?
It depends on the dialect. If we consider Common Lisp, it's a piece of data that doesn't constitute a valid form; it is calling 1 as a function. Some Lisp dialects off the mainstream path handle it. One that comes to mind is PicoLisp which admits (1 2 3) as an expression producing (1 2 3) (that object itself, essentially "auto-quoted", I think).
To be specific, it is data. It can also be code when placed in a context where code is expected (for example in the REPL).
If taken as code and evaluated it will probably raise some kind of exception (saying that '1' isn't a function). Saying that it isn't code because it raises an exception would be an interesting take, considering something like...
(sqrt "Hello, World!")
...would also raise an exception (something about wanting a number and getting a string) when evaluated, yet I doubt many people would argue that it isn't code.
Data can also be taken literally, as is the case when macros get involved. We do that every time we define a function, for example:
(defun square (x)
(declare (type Number x))
(* x x))
In this case the argument x is passed through a list which doesn't get evaluated as code.
And of course you can have conditional evaluating of data as code, which still makes it code even though it doesn't necessarily get evaluated:
the whole point of the "code is data" mantra is that it is both - the list `(1 2 3)` and the lisp code that evaluates to said list when parsed and interpreted.
You're basically asking if literals are code. I imagine you'll get varied opinions about that.
(And yes, that can be used unquoted in a few different contexts in Lisp, such as a special form or macro, or if you've managed to convince the reader that 1 is a function.)
I don't understand the question? In particular, it feels out of place? The common claim is that code is data. This does not necessarily imply that data is code.
That said, amusingly, `(1 2 3)` can easily be considered code if you are able to evaluate permutation notation. No?
It depends on the dialect. If we consider Common Lisp, it's a piece of data that doesn't constitute a valid form; it is calling 1 as a function. Some Lisp dialects off the mainstream path handle it. One that comes to mind is PicoLisp which admits (1 2 3) as an expression producing (1 2 3) (that object itself, essentially "auto-quoted", I think).
Yes.
To be specific, it is data. It can also be code when placed in a context where code is expected (for example in the REPL).
If taken as code and evaluated it will probably raise some kind of exception (saying that '1' isn't a function). Saying that it isn't code because it raises an exception would be an interesting take, considering something like...
...would also raise an exception (something about wanting a number and getting a string) when evaluated, yet I doubt many people would argue that it isn't code.Data can also be taken literally, as is the case when macros get involved. We do that every time we define a function, for example:
In this case the argument x is passed through a list which doesn't get evaluated as code.And of course you can have conditional evaluating of data as code, which still makes it code even though it doesn't necessarily get evaluated:
...which will only evaluate the literal list (1 2 3) when the may-error function is passed a boolean false value.the whole point of the "code is data" mantra is that it is both - the list `(1 2 3)` and the lisp code that evaluates to said list when parsed and interpreted.
wouldn't the data version be '(1 2 3) ? sorry I am just trying to understand
Usually yes. To distinguish between lists and function calls. However if we are to pass code literals to eval, we need to quote them:
You're basically asking if literals are code. I imagine you'll get varied opinions about that.
(And yes, that can be used unquoted in a few different contexts in Lisp, such as a special form or macro, or if you've managed to convince the reader that 1 is a function.)