>>>>>>Thank you. So far, the advantage (IMHO) in using the PRG without declaring the FUNCTION is that I don't have to SET PROCEDURE... Calling PRG should always work since it is in the .EXE. Since no one brought up any disadvantage(s) of using PRG without FUNCTION, I will go that route.
>>>>>
>>>>>There's another advantage: if you keep all of them in the same folder, you can't have duplicates, which is easy to do with set procedures. If a duplicate is detected it's actually not detected, the last one in a prg is the one (if in same prg), or the first declared one takes the day (or the last? haven't had that in years). So if you create such duplicate functions, you have just won the ticket to a whole afternoon debugging session.
>>>>>
>>>>>There are limitations, though - while any other filename can contain spaces etc, a prg-as-function has to have a name which conforms with the stricter rules for function names. Also, it has to be on the path, as you can't have a path in a function call. Both attempts here led to errors:
>>>>>
>>>>>? prgs\dcmake3()
>>>>>? "prgs\dcmake3"()
>>>>
>>>>On your point of spaces in the file name, I would never even think of creating a PRG with the space in the name. The only documents/files that I ever create with spaces in the name are Word documents. Pretty much 100% of other files I have created, I use the underscore ("_") if I need to separate words. So this limitation is not significant for me.
>>>>
>>>>I don't quite understand your point about "can't have a path is a function call". Why would I use the folder name in the function call? The function is in the .EXE so I would only call it as
>>>>? dcmake3()
>>>>
>>>>Thank you for your input.
>>>
>>>One big advantage is the exe is not filled with functions/procedures that are not required by the system.
>>
>>True.
>
>Here's another one: You have a massive .prg with a ton of functions. You want to enhance one of these. You make your code change. In order to run it you must compile it - which is slow because it's a huge pig - then set procedure to it - which used to be slow, but is certainly slower than just executing it because it's another command to execute, then execute the function. That inefficiency alone is worth stopping this outdated backward way of "organizing" code.

we're talking microseconds here. Its not relevant, or at the least, it should not be in VFP development.
Anyone who expects to see significant performance improvements by splitting up function libraries into seperate PRGs for the reason of performance will be dissapointment