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
Recognizer v4 API proposes to use accessors on a descriptor.
An accessor fetches from a descriptor the xt of an action that can be performed on a token. There are words like RECTYPE>COMP ( td -- xt-compiler ), RECTYPE>INT ( td -- xt-interpreter ), etc.
But it is simpler to use the words that do the corresponding actions instead using of the accessor. Some possible actions:
interpret-token ( i*x token{k*x} td -- j*x )
compile-token ( i*x token{k*x} td -- j*x )
translate-token ( i*x token{k*x} td -- j*x )
postpone-token ( token{k*x} td -- )
reproduce-token ( token{k*x} td -- )
drop-token ( token{k*x} td -- )
NB: the most of them are not demanded by programs, and so shouldn't be standardized.
Rationale
In the most cases a user/program needs just to perform the target actions. Getting an xt and then executing it has an excessive step without any profit.
E.g.
rectype>int execute vs interpret-token
rectype>comp execute vs compile-token
Perhaps an implementation of POSTPONE can be slightly better optimized if it relies on accessors. But POSTPONE is a standard word and its implementation may use the carnal knowledge. So, this reason isn't enough to standardize accessors.
NB: the run-time semantics compiled by reproduce-token can be to reproduce either the token, or the token and its descriptor, and what is better is needed to be analyzed.
In comparison with other actions, reproduce-token and drop-token are not connected to the source lexeme semantics.
The text was updated successfully, but these errors were encountered:
ruv
added
api
An API method semantics consideration
v4-review
Related to the proposal v4 by Matthias Trute
labels
Jun 10, 2020
ruv
changed the title
API: accessors vs target actions
API: accessors to methods vs higher level methods
Sep 7, 2020
Recognizer v4 API proposes to use accessors on a descriptor.
An accessor fetches from a descriptor the xt of an action that can be performed on a token. There are words like
RECTYPE>COMP ( td -- xt-compiler )
,RECTYPE>INT ( td -- xt-interpreter )
, etc.But it is simpler to use the words that do the corresponding actions instead using of the accessor. Some possible actions:
interpret-token ( i*x token{k*x} td -- j*x )
compile-token ( i*x token{k*x} td -- j*x )
translate-token ( i*x token{k*x} td -- j*x )
postpone-token ( token{k*x} td -- )
reproduce-token ( token{k*x} td -- )
drop-token ( token{k*x} td -- )
NB: the most of them are not demanded by programs, and so shouldn't be standardized.
Rationale
In the most cases a user/program needs just to perform the target actions. Getting an xt and then executing it has an excessive step without any profit.
E.g.
rectype>int execute
vsinterpret-token
rectype>comp execute
vscompile-token
Perhaps an implementation of
POSTPONE
can be slightly better optimized if it relies on accessors. ButPOSTPONE
is a standard word and its implementation may use the carnal knowledge. So, this reason isn't enough to standardize accessors.NB: the run-time semantics compiled by
reproduce-token
can be to reproduce either the token, or the token and its descriptor, and what is better is needed to be analyzed.In comparison with other actions,
reproduce-token
anddrop-token
are not connected to the source lexeme semantics.The text was updated successfully, but these errors were encountered: