"Python does have access to the abstract syntax tree of programs, but this is not for the faint of heart. On the plus side, the modules are easy to understand, and with five minutes and five lines of code I was able to get this:
>>> parse("2 + 2")
['eval_input', ['testlist', ['test', ['and_test', ['not_test', ['comparison',
['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term',
['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term', ['factor',
['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']]
-- Peter Norvig, https://norvig.com/python-lisp.html
That's not code as data, that's parsed code as data.
julia> :(a + b*c + 1) ==
Meta.parse("a + b*c + 1") ==
Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1)
true
> That's not code as data, that's parsed code as data.
I would say: you can execute it, therefore it's code. What am I missing?
> Why not just use a single representation (+ a (* b c) 1) ?
Are you saying you don't like the default print? You can write a println method for type Expr which prints it any way you want. Seems like a miniscule thing to nitpick.
You've convinced me, there is no difference.
Why wouldn't anyone want to write code like this:
Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1)If you remove the Expr, you get something that kind of looks like Lisp.
Yes, if you remove a few elements you get (+ a (* b c) 1), as I said a few messages back, which is lisp code and is also lisp data. So you can treat code as data!
You can of course parse code in any language and treat it as data (and it may resemble lisp code!) but it’s not quite the same thing.
Are you sure? Plenty of languages[1,2] allow you to treat code as data and they don't need that many parenthesis.
[1] https://docs.python.org/3.8/library/ast.html
[2] https://docs.julialang.org/en/v1/manual/metaprogramming/inde...