FunnelWeb V1 used a macro definition syntax that resulted in macro definitions such as the following.
@$@<Put out the cat@>==@{@-
Open the door
Say out
Close the door@}
This is messy, but I couldn't think of anything better at the time. The @$ is necessary to cue a definition. Without it, the definition might somehow be mistaken for an invocation. The @< and @> delimit the name. The @{ and @} delimit the text. The @- is a product of the rule exactly the text between the @{ and @}.
The only real target is the += and == which really break all the rules and should be changed. Unfortunately I couldn't think of anything to change them to. If there was no += mechanism, we could use:
@$@<Put out the cat@>@{
Open the door
Say out
Close the door@}
In fact, eliminating += is thinkable because it does not appear in many of my existing FunnelWeb source files. This indicates at least that it was not needed much by myself.
A minimalist construct could be
@<Put out the cat@> Open the door Say out Close the door@}
but this is too dangerous for my tastes.
Decision: For compatibility reasons, retain the old += and == constructs, but make them optional. The new syntax for defining macros is:
@$@<Put out the cat@>@{
Open the door
Say out
Close the door@}
Next we turn to parameterized macro definitions.parameterized macro definitionssyntax A conventional FunnelWeb parameterized macro definition looks like this:
@$@<Put out the cat@>@(@3@)==@{@-
Open the door
Say out
Close the door@}
which is a bit messy. The natural alternative is even worse:
@$@<Put out the cat@>@(@1@,@2@,@3@)==@{@-
Open the door
Say out
Close the door@}
Thus, just specifying the number of parameters seems sensible. However, perhaps the syntax could be trimmed to
@$@<Put out the cat@>@3==@{@-
Open the door
Say out
Close the door@}
I decided to reject this in favour of the old syntax.
Decision: Retain the old syntax of …@(@3@)…