APL was invented well before the widespread availability of file systems and text editors. Therefore it provided its own facilities to store and edit code (functions) and data, namely Workspaces and Component files. Most commercial APL systems of today still provide them, for continuity with existing installations and with developer expertise.
But those facilities date back to half a century ago and were designed for the hardware and interfaces of the time (mainframes and teletypes) which are to modern hardware as hand crank telephones are to smartphones.
Nowadays most developers would argue that code is best kept in (UTF-8 encoded) text files, edited with one's text editor of choice, and managed with a distributed version control system. I certainly subscribe to this view.
Some of the classical APL vendors have kept their offers "up to date" in this regard and provide facilities to deal with source code files, in a manner hopefully not too disjoint from workspaces. Dyalog APL has such a library called SALT - Simple APL Library Toolkit.
But the truth is, most APL systems don't have an easy command or function to load a source file because it's simply not used in practice. APL developers regard their APL system as an IDE, almost an OS. They keep everything inside workspaces and just use the editing windows provided by the system.
IMHO newer APL implementations (such as GNU APL and others) will eventually reject the concept of workspaces and align themselves with "modern" practices. But this is just my view, which is certainly not shared by the majority of APL programmers. Ask any of them about it and you will hear something along the lines of: ≪You can have my workspaces and component files when you pry them from my cold, dead fingers.≫