Pattern for implementing syntactic sugar

[nchammas]

Say I'm developing a language that lets you filter vehicle events on a timeline using an expression like this:

event(make = "honda" and date >= "2025-01-01" and type = "maintenance" and sub_type = "oil_change")

As a convenient shorthand for users, I would like to enable them to write something like this:

maintenance("oil_change")

Which is just syntactic sugar for this:

event(type = "maintenance" and sub_type = "oil_change")

In my Lark Interpreter implementation, I already have an implementation for event. Is there a "proper" way to implement maintenance so that it can reuse that implementation of event?

class VehicleQuery(Interpreter):
    @v_args(inline=True)
    def maintenance_expr(self, maintenance_type: str):
        ...
        return event_expr(...)

    def event_expr(self, node: Tree):
        ...

I am not sure how to construct the appropriate Tree to pass to event_expr from maintenance_expr. Is there some common way this is accomplished? Am I even approaching this problem correctly?

[erezsh]

I think the easiest solution would be to just use a shared helper. Something like this:

class VehicleQuery(Interpreter):
    @v_args(inline=True)
    def maintenance_expr(self, maintenance_type: str):
        return self._event_expr(...)

    @v_args(tree=True)
    def event_expr(self, node: Tree):
         self._event_expr(...)

    def _event_expr(self, make: str, type: str, ...):
         ...

It can also be an external function and not a method. But anyway, names that start with underscore are safe, Lark won't call them.

[nchammas]

That seems straightforward enough.

When would it be better to implement a separate "desugaring" Transformer that runs before the main Interpreter? Is that also a common approach to this problem or is it overkill?

[erezsh]

I think it's a good idea to first run a transformer that simplifies the tree (like folding operations on constants), and transforms the value nodes to convenient types or data structures.

I would maybe even restrict running transformers from the interpreter to only when strictly necessary. For example for evaluating dynamic code.