I take “sets of files” in this context as meaning named files stored in a filesystem on some kind of random access storage, and I take “present to the programmer” to imply that this filesystem should make its directory information (filenames) visible to the user.

Early computers presented source code to the compiler in the form of cards, paper tape or magnetic tape. They did not unify devices into the file system, so while the device might have a name the data currently loaded into it did not.

Embedded systems may be provided with an on-board compiler and read source code through a port.

The C/C++ addresses files by name but source code that has been pre-processed can certainly be read in from a reader or other device, compiled and executed in situ. I’m aware of this being done with Forth, and other languages are quite possible.

There were systems in which source code was stored in a database. The Pick system is the first that comes to mind, but there were others. Individual “files” were represented as records in a table in a database. This is kind of a file system by another name, but could certainly work. Perhaps it could be used for an interactive learning envirnonment, but I’m not aware of one.

As Basile hints in a comment, there are other ways to store source code than in text files.
VisualAge had the option to store it in a DB/2 database (worked with it, but never looked at the database) for example.
Borland’s C++ Builder stored some code in binary format (especially the code for the visual representation of screens) rather than text files. This does use files, just not text files.
And of course entire operating systems exist that don’t use files for storage, like the old Tandem NonStop operating system which used an SQL database as its filesystem.

I can conceive of an embedded system that stores data directly in EEPROM registers rather than as files on some device that then get read into that memory as required.
There are probably other options out there.