-
Notifications
You must be signed in to change notification settings - Fork 0
Operators
Some commonly used commands provide custom operator syntax as a low-punctuation alternative to standard command syntax, e.g. the standard library defines a custom while
operator syntax over the while
command so that:
‘while’ { TEST, repeat: ACTION }
can be written as:
while TEST repeat ACTION
Caution: library-defined operator syntax reserves symbolic and/or alphanumeric names for use in that syntax. e.g. The standard library reserves to
, if
, then
, else
, repeat
, while
, tell
, and other alphanumeric names. If a reserved name is used outside of its operator syntax, a syntax or other error will occur.
e.g. If operator syntax is not loaded, this is a valid command:
while { TEST, repeat: ACTION }
If operator syntax is loaded, the following are valid:
‘while’ { TEST, repeat: ACTION }
while TEST repeat ACTION
but this will produce a syntax error as the complete while TEST repeat ACTION
operator was not matched:
while { TEST, repeat: ACTION }
User caution: Take care when operator syntax is close to low-punctuation command syntax, e.g.:
while TEST repeat: ACTION
is a valid low-punctuation command only if the while
operator is not loaded. If the while
operator is loaded, the colon will cause a syntax error.
Developer caution: Avoid overuse of operator syntax, especially when reserving alphanumeric names which can conflict with names of commands used in user scripts. Reserved names can significantly affect how user scripts are parsed.
When a library-defined operator syntax is imported, it [currently] applies to the entire script. Consider if a custom operator syntax is warranted, minimize use of alphanumeric verbs and nouns, and favor command syntax where practical.
TO DO: operator import behavior needs to be stable and predictable within user scripts. For convenience, standard library commands and operators are imported by default (though one or both may be explicitly excluded). Importing a third-party library will not import its operators by default; these must be explicitly requested by the script. Library imports may/should/must be versioned to avoid ambiguity: a script may declare the versions of the libraries against which it was originally written, and it is up to the library importer to determine if a newer/older installed library is API compatible.
In addition to the punctuation characters described above, the following characters are reserved by iris:
. ? ! ;
Period, question, and exclamation marks can be used interchangeably with comma (,
) to separate/terminate expressions. Currently there is no difference in behavior, but in future custom interpreter behaviors may be assigned to each, e.g. ?
might invoke a debugger dialog upon evaluating the preceding command; !
might force a “destructive” command to be performed without displaying “Are you sure?” confirmation.
Semi-colons are used to “pipe” the output value of one command as the first argument to the next, e.g.:
say { read “Enter name:” }
may be sequentially written as:
read “Enter name:”; say
TO DO: This behavior may change in future to allow other arguments to be substituted using _
.
Annotations are delimited by «
and »
characters and may contain user documentation, code comments, TODOs, etc. The parser currently discards all annotations; this will change in future.
nothing
false
true
π
EXPR ^ EXPR
+ EXPR
- EXPR
EXPR × EXPR
EXPR ÷ EXPR
EXPR div EXPR
EXPR mod EXPR
EXPR + EXPR
EXPR - EXPR
(^
= exponent; *
is alias for ×
; /
is alias for ÷
)
EXPR = EXPR
EXPR ≠ EXPR
EXPR < EXPR
EXPR > EXPR
EXPR ≤ EXPR
EXPR ≥ EXPR
(<=
is alias for ≤
; >=
is alias for ≥
)
not EXPR
EXPR and EXPR
EXPR or EXPR
EXPR xor EXPR
EXPR is_same_as EXPR
EXPR is_not_same_as EXPR
EXPR is_before EXPR
EXPR is_after EXPR
EXPR is_not_before EXPR
EXPR is_not_after EXPR
EXPR begins_with EXPR
EXPR contains EXPR
EXPR ends_with EXPR
EXPR is_in EXPR
TO DO: these names may change and/or be aliased; TO DO: support comparing non-string types
EXPR & EXPR
EXPR is_a EXPR
EXPR as EXPR
(The right operand must be a type command, e.g. string
, editable list of: number
)
editable EXPR
optional EXPR
(The right operand is optional. If given, it must be a type command; if omitted, anything
is used.)
record EXPR
(The right operand is optional. If given, it is a record of form { label: type_command, … }
)
EXPR of EXPR
(These are used in aelib and behave as in AppleScript/SwiftAutomation.)
Reference forms:
EXPR at EXPR
EXPR named EXPR
EXPR id EXPR
EXPR from EXPR
EXPR whose EXPR
(at
= by-index; from
= by-range)
EXPR thru EXPR
(thru
is used as from
operator’s right operand. In future it may also be used to construct numeric ranges.)
EXPR before EXPR
EXPR after EXPR
(These are relative references. The left operand is an element type, e.g. document
)
Ordinals:
first EXPR
middle EXPR
last EXPR
any EXPR
every EXPR
Insertion location:
beginning
end
before EXPR
after EXPR
if TEST then ACTION
if TEST then ACTION else ALTERNATE_ACTION
while TEST repeat ACTION
TO DO: else
should be a binary operator, independent of if
, which can be composed with while
and other commands
set EXPR to EXPR
If the left operand is a name and set
does not appear in a tell
block, a new handler is defined in the current scope that returns the value of the right operand when invoked by the corresponding command:
✎ set name to “Bob”
☺︎ “Bob”
✎ name
☺︎ “Bob”
This provides variable-like behavior without needing a distinct “variable” type (name
is a command with no arguments).
Note that name-scope bindings are immutable (equivalent to bind-once variables):
✎ set name to “Bob”
☺︎ “Bob”
✎ set name to “Sam”
☹︎ «handler: ‘set’ …» failed on command: … Can’t modify immutable value.
To make a binding mutable, cast the right operand to editable …
:
✎ set age to 42 as editable
☺︎ editable 42
✎ age
☺︎ 42
This effectively binds an editable container that holds the initial value, which can be replaced with a new value:
✎ set age to 16
☺︎ 16
✎ age
☺︎ 16
TO DO: Left operand does not yet fully support references and multiple (list/record) binding.
Similar to AppleScript, “tell” blocks redirect commands (right operand) to the target object (left operand) instead of the current scope.
tell EXPR to ACTION
As an alternative to parentheses, groups may be delimited by do
and done
keywords:
do ( EXPR SEP )* done
to SIGNATURE run ACTION
when SIGNATURE run ACTION
(to
= command handler, describes actions to be performed; when
= event handler, responds to external notifications; a command handler errors upon receiving unknown arguments; an event handler ignores unknown arguments)
A handler signature consists of the handler’s name, optionally followed by a parameter record, optionally followed by returning
operator, the right operand of which is a type command describing the handler’s return value.