Sure... all code can be data if you want to look at it like that. Its just not a terribly useful place to argue from most of the time. Unless you plan on writing code that modifies or writes other code then you draw a line and your code isn't data.

See self-modifying. I've recently been spending time trying to treat perl code as data though most of the time there isn't much use to it. Most of my work is handled by perflectly mundane structures like hash tables, ordered lists, scalar variables. You can translate these concepts around into many different languages all of which eventually become machine language at which point the difference between code and data is what you plan to do with each.

For examples of perl code as data see (all of which have their own takes on the matter): Emily Dickenson in perl, Getting a code ref to main, Giving subroutines access to themselves, Auditing BEGIN blocks?, Trapping re 'debug', Allen Ginsberg - Is About, B::Deobfuscate - Deobfuscates symbol names and Module Modification at Runtime.

Added By the way - for canonical examples see Lisp macros, trampoline code (in particular linux trampoline because you can go find the source for that) and self-modifying assembly