Joe Tibollo wrote: > Also, a question for Chris - I know that APL workspaces store the binary > representations of the functions and variables to disk. However, why > can't we have our scripts and eat it too (sort of)? Why can't we store > the textual form of all the functions and variables (similar to the > solutions provided by Dan and Roger)? I haven't had a chance to > completely test out the solutions for saving and storing that have been > provided, but assuming they work, why not build that in to J. This does > not mean eliminating the loading of scripts - just something more. > Wouldn't it be nice to be able to load text scripts as you need them > (with all the advantages that has) and then when the workspace is > working the way you want - simply press a button or type save and your > work is preserved. No problem distributing your work. Whey does it > have to be 100% either way? Wouldn't that make the J environment more > productive? It would for me...
You could indeed save your work as big blobs of text in 5!:5 format as Dan and Roger point out, but this has most of the disadvantages of the stored APL workspace, and none of the advantages of scripts. By all means try it, but I think you will find it inconvenient. For example: How could you browse through it? You would have to load it in, then browse through what has appeared in the session. This is not as convenient as looking through source scripts. How do you update a definition? You would have to load it in, display the definition in the session, cut and paste the definition to a script window, edit the script window, load it back into the session and then save it (if you remember to save it). How do you update a definition that appears in several source files? What about search and replace? I do this all the time with scripts, but would be very hesitant on a big blob of 5!:5 text. How well do these blobs work with standard source code managers? How do you control what gets saved (the dustbin problem)? Remember that the J IDE has a ton of definitions that are inappropriate for an application. For example, if your app is a normal GUI, you don't want to save all the J code that supports the development session. Your point about having large numbers of definitions makes the script approach even more attractive. You can have as many scripts as you like, organized in directories, each with a manageable number of definitions. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
