You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chunk types are useful for efficient indexing of chunks, and for better readability. Types are used in rule conditions and for some rule actions, e.g. to recall a matching chunk. For external actions, the type is just one piece of information to be passed to the action's implementation, and may be redundant, e.g. console is redundant in the following action as the implementation is selected using the name provided with @Do.
console {@do log; message "hello world"}
Making the type optional would introduce an ambiguity between the chunk type and the already optional chunk identifier. We could perhaps modify the syntax to remove the ambiguity, e.g. requiring a colon before the chunk identifier if it is present without the chunk type. e.g.
dog dog1 {name fido}
:p23 {name mia}
{name smokey}
But that feels rather awkward. Another idea would be to place the chunk type as a property, so that the example becomes:
dog1 {type dog; name fido}
p23 {name mia}
{name smokey}
That's better, but reduces readability compared to the existing syntax:
For now at least, I would recommend retaining the existing syntax where the chunk type is required, and can be replaced by an asterisk if it is unknown.
The text was updated successfully, but these errors were encountered:
Chunk types are useful for efficient indexing of chunks, and for better readability. Types are used in rule conditions and for some rule actions, e.g. to recall a matching chunk. For external actions, the type is just one piece of information to be passed to the action's implementation, and may be redundant, e.g. console is redundant in the following action as the implementation is selected using the name provided with @Do.
Making the type optional would introduce an ambiguity between the chunk type and the already optional chunk identifier. We could perhaps modify the syntax to remove the ambiguity, e.g. requiring a colon before the chunk identifier if it is present without the chunk type. e.g.
But that feels rather awkward. Another idea would be to place the chunk type as a property, so that the example becomes:
That's better, but reduces readability compared to the existing syntax:
For now at least, I would recommend retaining the existing syntax where the chunk type is required, and can be replaced by an asterisk if it is unknown.
The text was updated successfully, but these errors were encountered: