Using macro as an abstraction layer

A lot depends on your intention. Data serialization in this manner just to pass on to the business logic of a single application, seems wasteful, when you should be passing a native object from the ORM to the object encapsulating BL which will modify state and return the object to the ORM for persistence.

On the other hand, if you have multiple, distributed applications that handle different aspects of of the domain, then wrapping your DB in an API to provide serialized (JSON or XML) data is a good idea.

For instance: I have to deal with a rather insane vendor-supplied legacy database in which a major constraint is inability to modify the DB schema other than adding the occasional view. I have this DB (as well as a couple of our other 'enterprise' data stores) wrapped in a REST API. Most of our user-facing applications, as well as daemons that monitor the DB for certain events, communicate with the API. In this way I can have the following workflow:

1. OR/M classes each wrap a single table in the DB. One object == one record.
2. Decorator classes handle presentation, including composition of more complex objects from simple model objects.
3. Controller classes respond to requests with a JSON representation of the object appropriate to the client application.
4. Clent processes data, POSTs or PUTs JSON object back to the API
5. Controller requests to save object, which is decomposed back to model objects and persisted by the O/RM.

This adds significant complexity.

If you have to deal with heterogeneous data stores, distributed applications, etc., this is an excellent solution. But unless you have those requirements, the rule of thumb is You Ain't Gonna Need It.

The linked questions identify a load of issues in current macro languages. If you're going to design a new language, you should address those those issues.

For instance, take the define TWO 1+1; TWO*TWO=3 example. You can make your language robust by not including a rule for 1+1*1+1; instead require arithmetic expressions to be explicitly parenthesized. That means 1+1*1+1 is a syntax error, and should be written as (1+1)*(1+1).