Attribute convenience
Calling att-value
is somewhat cumbersome.
Eg. (att-value 'xsmith_type node)
.
Similar for send
and choice objects.
The call-sites are longer than for normal procedures, more likely to involve extra lines, and they are more cumbersome to use as higher-order values (eg. for map).
Additionally, since the names are symbols, they aren't hygienic, and we use a prefix to “namespace” our built-in attributes.
Pierce dislikes this and defined a procedure render-node
to be called instead of using att-value
with xsmith_render-node
.
While I agree that using att-value
is cumbersome, I've never really liked the definition of render-node
.
I like that the different calling style of attributes highlights that they are not normal procedures -- attributes are hooked into RACRs caching system, etc.
I don't like having render-node
alone, being ONE attribute that you call in a different way.
I don't want to define functions for all of our attributes, because that doesn't match how users need to call attributes they define themselves.
We could make our xsmith macros define functions for each attribute automatically, but that itself has issues.
The functions would be defined in the module where assemble-spec-components
is used, and helper functions defined in other modules wouldn't be able to see them.
It would be frustrating and likely seem nonsensical for users who run into that issue.
So I have a proposal to allow a more convenient syntax for calling attributes, but that works equally well for user-defined attributes and core xsmith attributes, and is opt-in.
I propose that we create an xsmith/app
module that exports a #%app
macro.
This module will NOT be provided by the main xsmith library, and can be used at an individual fuzzer writer's discretion.
The #%app
implementation will check if the first item in the list is a quoted symbol, and if it is, generate code that checks the next item to see if it is an ast-node?
, and if so, run att-value
.
Otherwise, the #%app
falls back to the standard #%app
.
Another optional behavior is that we could have it automatically add the xsmith_
prefix, so instead of writing 'xsmith_render-node
you could just write 'render-node
.
We can also have it work for send
and choice objects (or instances of classes more generally).
As you know, I'm not necessarily fond of overriding #%app
because it's not very compositional.
Eg. if we had a mandatory custom #%app
, xsmith would not be compatible with eg. the fancy-app package, or another library that also requires a different custom #%app
.
But I'm perfectly happy with optional #%app
overrides, since they allow you to make a convenient choice at the module level.
@pdarragh are you happy with this plan? If so I'll go ahead and implement it. Otherwise, let's discuss. I frankly want to get rid of render-node
and have the interface for all attributes be consistent, but I do want to have a convenient way to call attributes that is less wordy and cumbersome than using att-value
directly.