Hi Blake,
A couple of corrections first. GNU APL never implemented )SIZE at all
(try it -- INCORRECT COMMAND). And the claim that )SIZE "is specified
in IBM's own APL2 Language Reference and Programming Guide manuals"
doesn't check out either -- I searched both (full text, including a
fresh PDF extraction of the LRM) and there's no )SIZE anywhere in
either one; the only size-related system command APL2 actually
documents is )SYMBOLS (query/modify the symbol table size), a different
thing. Then I tried it directly against the real IBM APL2 demo for PCs
-- also INCORRECT COMMAND. So )SIZE isn't just undocumented, it doesn't
exist in actual APL2 either. That part of the Claude answer was simply
fabricated -- I didn't know of a real )SIZE, no manual backs it up, and
now neither does the interpreter itself.
That said, your three points are all already covered, just under
different names:
1. Current memory usage -- no direct "bytes used" counter, but ⎕WA is
live (re-reads /proc/meminfo on every reference), so usage is
⎕WA-at-start minus ⎕WA-now.
2. Available before swapping -- this is exactly what ⎕WA already
reports. It reads /proc/meminfo's MemAvailable, which the kernel
itself defines as memory available for new processes without
swapping. Nothing to add here, it's already answering that question.
3. A settable max, useful for multi-processing -- already possible two
ways:
- --mem at startup: an absolute size (--mem 4G) or a percentage of
free memory (--mem 60%, 5-95% allowed).
- ⎕SYL[32;2] (WA_MARGIN, bytes) and ⎕SYL[33;2] (WA_SCALE, percent)
are both writable at runtime, not just reported -- so the cap can
be tuned after startup too, per process, which is the part that
matters for multi-processing.
So no need for a new )SIZE-alike command -- the pieces you actually asked
for are all there already, just split across ⎕WA/--mem/⎕SYL rather than
bundled under one name. Might be worth a paragraph in the manual pulling
these three together explicitly, since as your email shows it's not
obvious they're related unless you already know to look.
If anyone does recall a real )SIZE from APL\360 or APLSV days (i.e.
older than APL2), I'd be curious -- but for GNU APL's purposes it
doesn't matter either way, since we never modeled ourselves on it.
Cheers,
Juergen
PS: this reply, including the ⎕SYL row numbers and confirming they're
writable, was checked against a live GNU APL build with Claude Code.
On 8/29/26 18:14, Blake McBride wrote:
Greetings,
I seem to remember a )SIZE command from way back. I queried Claude
and found the following:
*Me: * Is the )SIZE command part of the IBM APL standard?
*Claude:*
Good question — worth distinguishing a couple of things here.
*)SIZE is not part of a formal international standard.* The formal APL
language standards (ISO/IEC 8485 for APL, and later ISO/IEC 13751 for
"Extended APL"/APL2-style features) define the /language/ — syntax,
primitive functions, operators, array semantics, etc. They generally
do *not* standardize system commands (the |)|-prefixed commands),
because those are considered part of the /interactive
session/workspace management/ layer, which is implementation-specific.
*)SIZE is, however, a long-standing IBM convention.* It originated in
IBM's APL implementations — APL\360, APLSV, and later APL2 — as part
of their documented system command set, and it's specified in IBM's
own APL2 Language Reference and Programming Guide manuals. Because
IBM's APL products were so influential, many other vendors (Dyalog,
GNU APL, APLX, etc.) adopted |)SIZE| or a close variant as a
convention for compatibility and familiarity, even though they aren't
obligated to by any standard.
So the accurate way to put it: |)SIZE| is a de facto standard
inherited from IBM's APL lineage, not a de jure one — it's part of
IBM's documented practice, but not part of the ISO APL language standard.
----------------
*Me: * Can you set the size of a workspace?
*Claude:*
Yes — |)SIZE| can be used both to query and to set the workspace size
limit, depending on the implementation.
*To query:* typing |)SIZE| alone reports the current active workspace
size (and often the maximum available).
*To set:* you follow it with a number, e.g.:
|)SIZE 4000 |
This requests a workspace size limit of 4000 (units vary by
implementation — often bytes, or sometimes a system-defined unit). A
few practical notes:
* *You can usually only shrink or grow within bounds.* Most
implementations let you /reduce/ the size freely, but /increasing/
it is capped by system-imposed limits (total memory available,
licensing limits, or an administrator-configured maximum). If you
ask for more than the system allows, it typically just sets it to
the maximum permitted rather than erroring out.
* *Timing matters.* In many implementations, |)SIZE| only takes
effect for variables/objects created /after/ the command — it
doesn't retroactively shrink space already occupied by existing
data, and if your existing workspace content already exceeds the
new requested size, the request may be rejected or clamped.
* *Some implementations tie )SIZE to sign-on time only.* In older
mainframe-style APL systems (e.g., timesharing APL\360/APLSV),
workspace size was sometimes fixable only during login/sign-on,
not mid-session. Modern implementations like Dyalog APL and GNU
APL are generally more flexible and let you resize mid-session,
memory permitting.
If you tell me which specific APL system you're working in (Dyalog,
GNU APL, APL2, etc.), I can give you the precise syntax and behavior
for that one, since the exact units and constraints do vary.
-------------------------------------------------------
I am trying to think if )SIZE makes any sense in today's environment.
I think the following would be worth knowing:
1. How much memory the system is currently using. This would redilly
point out when you are taking up a lot more memory then you expect.
2. How much memory is available before going into virtual memory.
3. Being able to set a max memory usage can be helpful in a
multi-processing system.
Just some thoughts.
Blake
