The document I have of the RISCV instruction set doesn't specify
symmetric or floored division for the DIV instruction, either way!
Note: instruction set manuals for RISCV are hard to come by.
Instead of an absolute autoritive instruction manual for i86
by Intel, are there now competing, possibly incomplete manuals by
each supplier?
So should I continue with changing from symmetric to floored?
...
So should I continue with changing from symmetric to floored?
The division in ciforth was default symmetric. The motivation is that
SM/REM is a wrapper for the single instruction IDIV while floored
is more complicated.
Signed division has a speed advantage for modular arithmetic too.
[
Normalizing a remainder to the range 0 .. _m is easily done by
: _norm_-m DUP 0< _m @ AND + ;
(Note that all constituents are assembler primitives, such that
they can be collated into one assembler word.)
]
There are m modulo classes modulo m. Then it embarrasses mathematicians
that `` I1 @ m MOD '' and `` I2 @ m MOD '' are not equal,
despite i1 and i2 having the same modulo class.
Symmetric division:
2 3 MOD .
2 OK
-1 3 MOD .
-1 OK
So gforth (at least 0.7.3) avoids this
2 3 MOD . 2 ok
-1 3 MOD . 2 ok
...
On 9/11/2025 12:47 am, albert@spenarnc.xs4all.nl wrote:
The division in ciforth was default symmetric. The motivation is that
SM/REM is a wrapper for the single instruction IDIV while floored
is more complicated.
Signed division has a speed advantage for modular arithmetic too.
[
Normalizing a remainder to the range 0 .. _m is easily done by
: _norm_-m DUP 0< _m @ AND + ;
(Note that all constituents are assembler primitives, such that
they can be collated into one assembler word.)
]
There are m modulo classes modulo m. Then it embarrasses mathematicians
that `` I1 @ m MOD '' and `` I2 @ m MOD '' are not equal,
despite i1 and i2 having the same modulo class.
Symmetric division:
2 3 MOD .
2 OK
-1 3 MOD .
-1 OK
So gforth (at least 0.7.3) avoids this
2 3 MOD . 2 ok
-1 3 MOD . 2 ok
...
2 3 MOD . 2 ok
-1 3 MOD . 0 ok
All 'mod' operators in polyForth were unsigned ;-)
In article <6910400f$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 9/11/2025 12:47 am, albert@spenarnc.xs4all.nl wrote:
The division in ciforth was default symmetric. The motivation is that
SM/REM is a wrapper for the single instruction IDIV while floored
is more complicated.
Signed division has a speed advantage for modular arithmetic too.
[
Normalizing a remainder to the range 0 .. _m is easily done by
: _norm_-m DUP 0< _m @ AND + ;
(Note that all constituents are assembler primitives, such that
they can be collated into one assembler word.)
]
There are m modulo classes modulo m. Then it embarrasses mathematicians
that `` I1 @ m MOD '' and `` I2 @ m MOD '' are not equal,
despite i1 and i2 having the same modulo class.
Symmetric division:
2 3 MOD .
2 OK
-1 3 MOD .
-1 OK
So gforth (at least 0.7.3) avoids this
2 3 MOD . 2 ok
-1 3 MOD . 2 ok
...
2 3 MOD . 2 ok
-1 3 MOD . 0 ok
All 'mod' operators in polyForth were unsigned ;-)
Interesting. I didn't think of that alternative.
However that is only useful in modular arithmetic.
There is a simple way to detect overflow in modular addition,
for signed numbers.
: _norm_-m DUP 0< _m @ AND + ; ( x -- xn ) \ -m<x<+m
: +m + _m @ - _norm_-m ; ( an bn -- sumn )
That can be changed to usigned, probably.
As long as you restrict the modulo to a number less than 8000,0000,0000,0000 this might work equally well for unsigned numbers.
For modulo arithmetic each input has to be in the range 0 .. _m @ .
As numbers are normally unsigned, restricting MOD to unsigned number
is not an option in my opinion. Also it is a gratitious deviation from
ISO 94, a big nono.
...
I can't think of that many instances where I've used signed division.
Are
there use cases for floored? Sure. But if the argument be 'a positive mod >is best' then floored doesn't guarantee that.
dxf <dxforth@gmail.com> writes:
I can't think of that many instances where I've used signed division.
When Gforth switched from symmetric to floored for / MOD, etc., there
were no complaints that I remember.
This lack of complaints indicates that division with negative operands
either does not occur, or that it occurs, but the users wanted floored >division and have not used the earlier symmetric /, MOD etc., but have
used FM/MOD instead.
In the latter case, the users might have started using /, MOD etc. for
such cases in the meantime, and switching back might lead to
complaints. We are not going to switch back to find that out.
There have been regular discussions of floored vs. symmetric division,
and the Forth-83 standardization committee found it important enough
to specify that /, MOD etc. are floored, so division with negative
operands is at least on the mind of people.
Forth-94 specified /, MOD etc. as implementation-defined, which has
led to the regular discussions mentioned above.
Bernd Paysan, who switched Gforth to floored, used to work on >signal-processing equipment for audio applications. These signals
tend to be signed numbers (for positive and negative voltages), and
when you scale them with */, rounding towards 0 leads to flatness when
the signal passes through 0 that was not there in the original signal. >Floored division avoids that; rounded division may avoid that, too,
but the round-towards-even tie-breaker is probably a problem.
Are
there use cases for floored? Sure. But if the argument be 'a positive mod >>is best' then floored doesn't guarantee that.
If the divisor is positive, the result of floored MOD is >=0.
If you have negative divisors and want results that are >=0, there is
also something called "Euclidean division" ><https://en.wikipedia.org/wiki/Euclidean_division> where the remainder >satisfies 0<=remainder<|divisor|.
As long as the divisor is positive, the result of Euclidean division
and floored division are the same, and the remainders are the same,
too.
If you look at ><https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages>, >you find that there are some programming languages that specify
Euclidean modulo, sometimes just that and sometimes in addition to
symmetric ("truncated" in the table) or rounded; there seems to be no >language that has both Euclidean and floored, which may indicate that
the cases where they differ (i.e., negative divisors) occur too rarely
to provide both. In any case, the variants and the page itself
indicate that the topic is not just on the minds of the Forth
community.
- anton
dxf <dxforth@gmail.com> writes:
I can't think of that many instances where I've used signed division.
When Gforth switched from symmetric to floored for / MOD, etc., there
were no complaints that I remember.
...
On 10/11/2025 5:46 pm, Anton Ertl wrote:
dxf <dxforth@gmail.com> writes:
I can't think of that many instances where I've used signed division.
When Gforth switched from symmetric to floored for / MOD, etc., there
were no complaints that I remember.
...
Forth-83 got complaints. So much so that it put the fear of Akhenaten
into the following committee.
In article <6911ca81$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 10/11/2025 5:46 pm, Anton Ertl wrote:
dxf <dxforth@gmail.com> writes:
I can't think of that many instances where I've used signed division.
When Gforth switched from symmetric to floored for / MOD, etc., there
were no complaints that I remember.
...
Forth-83 got complaints. So much so that it put the fear of Akhenaten
into the following committee.
Gforth gets none. The world has progressed.
I don't like it that a simple program
ported from ciforth versus gforth or vice versa stops working because
of floored/symmetric.
dxf <dxforth@gmail.com> writes:
I can't think of that many instances where I've used signed division.
When Gforth switched from symmetric to floored for / MOD, etc., there
were no complaints that I remember.
This lack of complaints indicates that division with negative operands
either does not occur, or that it occurs, but the users wanted floored >division and have not used the earlier symmetric /, MOD etc., but have
used FM/MOD instead.
- anton--
albert@spenarnc.xs4all.nl writes:You got me there. It is highly hypothetical.
I don't like it that a simple program
ported from ciforth versus gforth or vice versa stops working because
of floored/symmetric.
Do you have such programs?
- anton--
Have you got programs ported from elsewhere that have problems
on gforth, given that gforth is more widely used?
In article <2025Nov10.074620@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
dxf <dxforth@gmail.com> writes:
I can't think of that many instances where I've used signed division.
When Gforth switched from symmetric to floored for / MOD, etc., there
were no complaints that I remember.
This lack of complaints indicates that division with negative operands
either does not occur, or that it occurs, but the users wanted floored
division and have not used the earlier symmetric /, MOD etc., but have
used FM/MOD instead.
Indeed. The intent of the 94 standard was that one can choose
where it matters and ignore where it doesn't matter.
That makes the choice less important.
The TC effectively pushed the problem of standardizing division into the >future, hoping future forthers and Standard would resolve it.
The same
for NOT (another '83 blunder). But as is often the case, what is put off
is never completed.
dxf <dxforth@gmail.com> writes:
The TC effectively pushed the problem of standardizing division into the
future, hoping future forthers and Standard would resolve it.
Another way to view it is that Forth-94 provides FM/MOD and SM/REM for
those who need a specific behaviour and /, MOD etc. for those who
don't.
As for common practice, which would be the foundation of standardizing
one behaviour, among the Forth systems that I often check, on
iforth, lxf, SwiftForth64, and VFX64 / is symmetric, and on gforth it
is floored.
BTW, another advantage of floored / is that "2 /" and 2/ have the same result.
The same
for NOT (another '83 blunder). But as is often the case, what is put off
is never completed.
Forth-94 has 0= that takes 0/non-zero inputs and produces flag outputs
(i.e., like the Forth-79 NOT, except that TRUE is all-bits-set in
Forth-94), and INVERT for the Forth-83 NOT. These words have
certainly been good enough in my work for the last three decades. Do
we really need NOT?
Apparently some people have the desire, so 4 out of 5 systems that I
often check include a NOT. Is there common practice there? iForth,
lxf, and SwiftForth64 have a NOT that behaves like 0=, while VFX64 has
a NOT that behaves like INVERT. Gforth does not have a NOT.
So no common practice has emerged for / nor for NOT, so it is unlikely
that (more) standardization will happen in this area soon.
dxf <dxforth@gmail.com> writes:
The TC effectively pushed the problem of standardizing division into the
future, hoping future forthers and Standard would resolve it.
Another way to view it is that Forth-94 provides FM/MOD and SM/REM for
those who need a specific behaviour and /, MOD etc. for those who
don't.
As for common practice, which would be the foundation of standardizing
one behaviour, among the Forth systems that I often check, on
iforth, lxf, SwiftForth64, and VFX64 / is symmetric, and on gforth it
is floored.
BTW, another advantage of floored / is that "2 /" and 2/ have the same result.
The same
for NOT (another '83 blunder). But as is often the case, what is put off
is never completed.
Forth-94 has 0= that takes 0/non-zero inputs and produces flag outputs
(i.e., like the Forth-79 NOT, except that TRUE is all-bits-set in
Forth-94), and INVERT for the Forth-83 NOT. These words have
certainly been good enough in my work for the last three decades. Do
we really need NOT?
Apparently some people have the desire, so 4 out of 5 systems that I
often check include a NOT. Is there common practice there? iForth,
lxf, and SwiftForth64 have a NOT that behaves like 0=, while VFX64 has
a NOT that behaves like INVERT. Gforth does not have a NOT.
So no common practice has emerged for / nor for NOT, so it is unlikely
that (more) standardization will happen in this area soon.
dxf <dxforth@gmail.com> writes:
The TC effectively pushed the problem of standardizing division into the >>future, hoping future forthers and Standard would resolve it.
Another way to view it is that Forth-94 provides FM/MOD and SM/REM for
those who need a specific behaviour and /, MOD etc. for those who
don't.
As for common practice, which would be the foundation of standardizing
one behaviour, among the Forth systems that I often check, on
iforth, lxf, SwiftForth64, and VFX64 / is symmetric, and on gforth it
is floored.
BTW, another advantage of floored / is that "2 /" and 2/ have the same >result.
The same
for NOT (another '83 blunder). But as is often the case, what is put off >>is never completed.
Forth-94 has 0= that takes 0/non-zero inputs and produces flag outputs
(i.e., like the Forth-79 NOT, except that TRUE is all-bits-set in
Forth-94), and INVERT for the Forth-83 NOT. These words have
certainly been good enough in my work for the last three decades. Do
we really need NOT?
Apparently some people have the desire, so 4 out of 5 systems that I
often check include a NOT. Is there common practice there? iForth,
lxf, and SwiftForth64 have a NOT that behaves like 0=, while VFX64 has
a NOT that behaves like INVERT. Gforth does not have a NOT.
So no common practice has emerged for / nor for NOT, so it is unlikely
that (more) standardization will happen in this area soon.
- anton--
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html >comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/
Discussions like this remind me of the saying, ‘fly with the
eagles or scratch with the chickens’. Getting worked up about remainder
or modulus after decades of Forth doesn't get us anywhere, it's only
good for the chickens. There are other 'eagle' areas that need work,
such as libraries.
But Forth no longer has the critical mass for eagle topics, neither in
the software industry nor in the open source or hobby sector.
Am 12.11.2025 um 08:16 schrieb Anton Ertl:
dxf <dxforth@gmail.com> writes:
The TC effectively pushed the problem of standardizing division into the >>> future, hoping future forthers and Standard would resolve it.
Another way to view it is that Forth-94 provides FM/MOD and SM/REM for
those who need a specific behaviour and /, MOD etc. for those who
don't.
As for common practice, which would be the foundation of standardizing
one behaviour, among the Forth systems that I often check, on
iforth, lxf, SwiftForth64, and VFX64 / is symmetric, and on gforth it
is floored.
BTW, another advantage of floored / is that "2 /" and 2/ have the same
result.
The same
for NOT (another '83 blunder). But as is often the case, what is put off >>> is never completed.
Forth-94 has 0= that takes 0/non-zero inputs and produces flag outputs
(i.e., like the Forth-79 NOT, except that TRUE is all-bits-set in
Forth-94), and INVERT for the Forth-83 NOT. These words have
certainly been good enough in my work for the last three decades. Do
we really need NOT?
Apparently some people have the desire, so 4 out of 5 systems that I
often check include a NOT. Is there common practice there? iForth,
lxf, and SwiftForth64 have a NOT that behaves like 0=, while VFX64 has
a NOT that behaves like INVERT. Gforth does not have a NOT.
So no common practice has emerged for / nor for NOT, so it is unlikely
that (more) standardization will happen in this area soon.
Agreed.
Discussions like this remind me of the saying, ‘fly with the
eagles or scratch with the chickens’. Getting worked up about remainder
or modulus after decades of Forth doesn't get us anywhere, it's only
good for the chickens. There are other 'eagle' areas that need work,
such as libraries.
But Forth no longer has the critical mass for eagle topics, neither in
the software industry nor in the open source or hobby sector.
But to remain constructive: it is positive that at least the existing standard is being maintained.
On 12/11/2025 9:13 pm, minforth wrote:<SNIP>
Discussions like this remind me of the saying, ‘fly with the
eagles or scratch with the chickens’. Getting worked up about remainder
or modulus after decades of Forth doesn't get us anywhere, it's only
good for the chickens. There are other 'eagle' areas that need work,
such as libraries.
But Forth no longer has the critical mass for eagle topics, neither in
the software industry nor in the open source or hobby sector.
But to remain constructive: it is positive that at least the existing
standard is being maintained.
Protected, yes. It should be renamed the FSC - Forth Security Council.
In article <6915a4cf$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 12/11/2025 9:13 pm, minforth wrote:<SNIP>
Discussions like this remind me of the saying, ‘fly with the
eagles or scratch with the chickens’. Getting worked up about remainder >>> or modulus after decades of Forth doesn't get us anywhere, it's only
good for the chickens. There are other 'eagle' areas that need work,
such as libraries.
But Forth no longer has the critical mass for eagle topics, neither in
the software industry nor in the open source or hobby sector.
But to remain constructive: it is positive that at least the existing
standard is being maintained.
Protected, yes. It should be renamed the FSC - Forth Security Council.
There are sufficient eagles here.
Your remark make me suspect that
you have not much real life experience in the field.
On 13/11/2025 8:58 pm, albert@spenarnc.xs4all.nl wrote:<SNIP>
In article <6915a4cf$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
There are sufficient eagles here.
Is that what they call themselves?
Your remark make me suspect that
you have not much real life experience in the field.
What field is that? Luckily I never reached the level where I had to kiss ass.
minforth <minforth@gmx.net> writes:
Discussions like this remind me of the saying, ‘fly with the
eagles or scratch with the chickens’. Getting worked up about remainder
or modulus after decades of Forth doesn't get us anywhere, it's only
good for the chickens. There are other 'eagle' areas that need work,
such as libraries.
But Forth no longer has the critical mass for eagle topics, neither in
the software industry nor in the open source or hobby sector.
I don't think that you need a critical mass for eagle stuff, on the
contrary, the eagle stuff tends to first come up in research projects
where only a few people work on it and use it. And then the stuff is
either forgotten (as seems to happen with the Ivy/Deputy work <http://ivy.cs.berkeley.edu/ivywiki/uploads/deputy-manual.html>), or
it spreads slowly, in a winding way until it finds acceptance in the mainstream.
An example of the latter is the Edinburgh LCF project for a theorem
prover; the theorem prover is long forgotten, but in the course of
this research Robin Milner and his collaborators developed ML with
many eagle features, among them type inference. ML and its offspring, Standard ML, Ocaml, and F# have been minority languages since then,
but at least not died out. Type inference has spread, first to other minority languages, in the last decade or so to mainstream languages
like Java.
Rust was worked on as a personal project by Graydon Hoare starting in
2006. He wrote <http://venge.net/graydon/talks/intro-talk-2.pdf> that
there is "hardly anything" new in Rust and mentions a number of
languages that Rust picks from. To me it looks like it is strongly influenced from ML in many respects, not just type inference; the most obvious other feature from ML is what Rust calls enumerations, and the matching; however, in many respects Rust is different from ML, in
particular it is designed for imperative programming, whereas ML is
designed for functional programming. Interestingly, Hoare does not
mention ML (even though the first Rust compiler was written in Ocaml),
but maybe that influence has come through one of the other languages
he mentions. Rust has later become a Mozilla project, and later
became independent of Mozilla; it is gaining popularity, and may
become mainstream soon.
Bottom line: eagle stuff starts small and takes a long while to
spread. You don't need "critical mass" to develop eagle stuff. You
just develop it, and if you are lucky, it spreads and becomes
mainstream.
A standard for an existing language is not the place to introduce
eagle stuff. This is particularly true of standards based on common
practice like the Forth standard; in some other languages (Java, C++)
the standard leads and the implementations follow, but Forth is not
one of these languages.
Back to Forth:
The most eagle-like thing in the standards work is recognizers, and it
seems like we are reaching a consensus among the standardization
committee <https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#contribution-412>.
But note that the late Matthias Trute implemented recognizers in
amForth in 2011, and he made a proposal for standardization in 2014.
Bernd Paysan picked up recognizers pretty soon, VFX and other systems
have also picked them up, but then we needed 11 years to reach a
consensus in the committee; and I hope it holds, and we will have the
final decision soon; in the meantime, if you have any feedback on the proposal, please add it as a reply to the proposal; note that, while
name changes (bikeshedding) are always a favourite among repliers, the
names in the proposal have been found in lengthy discussions among the committee, and are unlikely to change.
As for other eagle features, you have to look at systems. E.g., in
Gforth we have closures <https://net2o.de/gforth/Closures.html>, multi-tasking with message queues <https://net2o.de/gforth/Message-queues.html> (although the actor
model also started in 1973, like ML), user-defined TO (etc.) behaviour <https://net2o.de/gforth/Words-with-user_002ddefined-TO-etc_002e.html>, user-defined "COMPILE," <https://net2o.de/gforth/User_002ddefined-compile_002dcomma.html>, and
you can set interpretation and compilation semantics of a word pretty arbitrarily <https://net2o.de/gforth/Header-methods.html>, which has
made it possible to implement, e.g., FORWARD <https://net2o.de/gforth/Calls-and-returns.html#index-forward-_0028-_0022name_0022-_002d_002d-_0029-gforth_002d1_002e0>.
Maybe other Forth systems will pick some of these features up, maybe
they won't.
One area where there has been a lot of work in recent times is in the programming environment, with stuff like Gforth's status bar, VFX's
status prompt, LOCATE and WHERE spreading and getting new features.
Does this stuff need standardization? I don't think so, because it
does not occur in programs that you want to port. OTOH, we have a
number of such words standardized (e.g., WORDS), so maybe we should standardize these words, too, for "programmer portability", as IIRC
Elizabeth Rather put it.
In article <6915bff1$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 13/11/2025 8:58 pm, albert@spenarnc.xs4all.nl wrote:<SNIP>
In article <6915a4cf$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote: >>> There are sufficient eagles here.
Is that what they call themselves?
Apparently that is what you call yourself. The eagles that can
ignore standards. I'm not one of those.
Quotations are rather unwieldy for normal users,
and recognizers are more for people who want to extend the Forth >interpreter/compiler, which most normal users probably don't do.
By 'low critical mass' I meant that there are hardly any normal users.
Most of the few users are specialists, and many primarily maintain their
own systems.
I compare it a little to Lua. Even though the hype around LuaJit has >subsided somewhat, there is a large user base, industry customers, and
an active community. However, Lua also supports working with user data
more than Forth, which does not even recognize dynamic strings in the >standard. UTF-8 is also not supported (the XCHAR wordset is only >rudimentary).
But if Forth is primarily a toolbox for small systems, nothing will
happen in this direction.
OTOH multitasking or the integration of driver
libraries are two 'eagle' topics which could serve the small system
domain.
minforth <minforth@gmx.net> writes:
Quotations are rather unwieldy for normal users,
That's funny, because the more common complaint has been that they are
just syntactic sugar that offer no functional benefit compared to
putting the definition in a named word, and ticking that. The latter
is true, but as Stephen Pelc says, notation matters.
...
On 17/11/2025 3:13 am, Anton Ertl wrote:
minforth <minforth@gmx.net> writes:
Quotations are rather unwieldy for normal users,
That's funny, because the more common complaint has been that they are
just syntactic sugar that offer no functional benefit compared to
putting the definition in a named word, and ticking that. The latter
is true, but as Stephen Pelc says, notation matters.
...
Only yesterday I was working with code containing quotations. What jumped
at me (which I'd known from previous experience) is what a PITA they are to >document. Unwieldy? You couldn't pay me enough. I'd rather work with >:NONAMEs (lesser of the nameless evils). Even H.P. Lovecraft was forced to >name his. What use is a god that doesn't have a name?
In article <691a6906$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 17/11/2025 3:13 am, Anton Ertl wrote:\ An example from MANX
minforth <minforth@gmx.net> writes:
Quotations are rather unwieldy for normal users,
That's funny, because the more common complaint has been that they are
just syntactic sugar that offer no functional benefit compared to
putting the definition in a named word, and ticking that. The latter
is true, but as Stephen Pelc says, notation matters.
...
Only yesterday I was working with code containing quotations. What jumped >> at me (which I'd known from previous experience) is what a PITA they are to >> document. Unwieldy? You couldn't pay me enough. I'd rather work with
:NONAMEs (lesser of the nameless evils). Even H.P. Lovecraft was forced to >> name his. What use is a god that doesn't have a name?
\ SILVER is the instrument met aluminium tubes metallophone.
\ REALTIME-TASKS is a set of task that must be executed as soon
\ as they are viable.
\-----------------------------
\ Activate or deactivate the hammer of EVENT.
: TOGGLE-NOTE-SILVER SILVER-DATA SILVER-INTERFACE ADVANCE-NOTE ;
\ The real time action of the silver tingle.
: RT-SILVER SILVER-QUEUE ['] TOGGLE-NOTE-SILVER TRY ;
' RT-SILVER REALTIME-TASKS SET+
\-----------------------------
With anonumous quotation { } this becomes
\ The real time action of the silver tingle.
{ SILVER-QUEUE { SILVER-DATA SILVER-INTERFACE ADVANCE-NOTE } TRY } REALTIME-TASKS SET+
At least it is more compact. More readable? At least it doesn't waste dictionary space and burden the memory.
"ORANG UTAN" works in both interpretation state and compilation state.
{ } should do too.
SILVER-QUEUE SILVER-DATA and SILVER-DATA makes an object current.
It serves the same purpose as dragging the whole environment into
a quotation, but much cleaner.
In words:
We add an attempt to execute an event present in the silverqueue.
The action is beginning and terminating a note, in the context of
SILVER-DATA (determines which note couple to a midi event)
and SILVER-INTERFACE (how the parallel port is to be controlled for
the silver metallophone.)
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,089 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 153:53:28 |
| Calls: | 13,921 |
| Calls today: | 2 |
| Files: | 187,021 |
| D/L today: |
3,760 files (944M bytes) |
| Messages: | 2,457,163 |