> How should this behave in a nested load? And, why? Exactly my chief concern. That's why I'd steer clear of schemes to abort the load -- or rather, abort execution of the file which presumably has been read-in whole-and-entire somewhere. The scheme should behave *for all purposes* like loading a truncated script.
> Before jumping too deeply into the details, it would be good to have an idea of what this solves and why we're doing it? I agree entirely. That's why I posted it on Chat first. I offered a list of reasons why in my initial post. It's too early to be a "programming" exercise. We first need to talk about Tasks, and then we can get a handle on Task Support. I can only propose what would really suit me for all my tasks, and ask if others share my needs enough to build the facility deeply into J --as deeply as the naked right-parenthesis, say. I can think of dozens of mickey-mouse schemes coded in pure J and residing in stdlib, but eventually they'll all turn round and bite you. Chris gives an example. Make it part of load, or script/scriptd, and how does the script behave if you use (0!:) ? If you only ever work with multi-file source in a "project" and never see the need to work with a single all-purpose script, then you won't see the need for this facility. Now I use Xcode, and Logic pro, and have used Dreamweaver – and all these IDEs are "I-" for "Integrated". They support – and in some cases *demand* – a multi-file source in a tight bundle called a "project" (.c-files, .h-files, css files, .plist files –the list proliferates.) But all these IDEs thoroughly integrate the source files in the bundle. More thoroughly than does J in any of its IDEs. So thoroughly you can scarcely tell if you're dealing with multiple files or just multiple windows into the same file. Right now I'm using Xcode to manage a suite of J scripts – and I find it more convenient than jqt. But that may be because the J suite is just one component of a Swift-based app. But IMO multi-file "projects" are overkill for J, unless the app is a collection of separately-developed modules or utilities. Then the verb (require) does what's necessary for integration. Why am I so sanguine? Because (…in case it's escaped people's notice :-) J has this property that it takes one line to code what in most other languages takes 10-20 lines. I believe in engineering an app from separately-developed and tested components. To me, every script is a "component". I want misc notes (with no syntactical if-buts) plus debug code to be part of all my scripts during development and testing, but "stripped off" in operational use. YET kept firmly together with the script. Then I won't need a monster IDE to manage my projects. Just a folder or two. The present suggestion would allow 1-script apps to be developed, and much of the script's contents to be effectively deleted before shipping, or operational use, or multiple uses. Only not deleted, but kept harmlessly as part of the script in case it needs upgrading or migrating. Typically the last for me means running a package as a standalone app, effectively a test-rig for the utility I'm developing, but destined to be a component in a greater app. I hazard a guess that most of the existing addons would benefit by being organised as a single script -- including manifest.ijs and any test scripts (…if you can find them). You wouldn't need an IDE to develop them: just a ~user folder plus a ~temp folder. …Anyway, that's my "task analysis". What do other people need? On Wed, May 9, 2018 at 3:09 PM, Raul Miller <[email protected]> wrote: > How should this behave in a nested load? And, why? > > Also, have you considered tactics like: > > 3 :’throw.’0 > > ? > > Thanks, > > — > Raul > > > On Wednesday, May 9, 2018, Ian Clark <[email protected]> wrote: > > > Can I propose we agree to alter the stdlib verb: (load) to provide a way > to > > stop loading a given script? > > > > @@NB. stop loading at this line > > > > …certainly does that, but generates an unwelcome "syntax error". This can > > interfere with calling processes. > > > > I propose @@@… (three or more) as the conventional end-of-script marker. > A > > line of @@@… offers a clear marker to draw attention to what's happening. > > > > There are a number of reasons why you might want to do this: > > > > ++ to partly-load a script for testing > > > > ++ to omit test code for operational use > > > > ++ to keep notes at the bottom of a script (as I do) > > 0 :0 NB. a block of notes > > or > > Note 'a block of notes' > > …has the disadvantage of turning off syntax coloring, also resuming > > interpreting code as soon as it hits an isolated right parenthesis. > > > > Ian Clark > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
