I wonder if a different way to approach the problem is to use the reverse of how the PREPARE keyword worked in lab files to isolate the behind the scenes preparations. Could we use a SKIP keyword that toggles on and off as you process the script. It would be closer to the kdb / / solution but would be a bit more visible. It would also be a bit more general than the @@@ which is really an end of file marker and would not allow you to skip sections of file unless they are at the end. SKIP would allow you to isolate sections that would not be processed.
In order to load a file using SKIP I would imagine that you would have a preprocessing script that would take out the SKIPped sections and then pass them along to load or loadd as required. So a script that looked like this average=: +/ % # SKIP any information I may want to include in terms of notes as many lines as I would like SKIP chaos=: ? 1000 $ 1000 SKIP load test cases SKIP average chaos would only pass along the definitions of average and chaos and the request to produce the result to load and would ignore notes and test cases. It is possible that in the preprocessing that you may be able to use text colouring to make the sections that are not processed more obvious. Perhaps a medium grey to indicate inactive? Just some thoughts. It does introduce an extra level for a script to run through, but it seemed to work pretty well with PREPARE in labs. There was also a SCRIPT keyword in labs that may actually work as well, but would only create SCRIPTed sections and I think that I would prefer to SKIP sections more than I would want to have to define every part of the script to pass forward. I never used SCRIPT very often. Cheers, bob > On May 9, 2018, at 7:00 AM, chris burke <[email protected]> wrote: > > I have often wondered about this. > > In my own practice, I use Fraser Jackson's Note convention which I think > works very well. The lack of syntax coloring is a minor issue. Also, Jqt > supports add/delete Note from the keyboard with Ctrl+Shift+/ . > > The problem with any convention like @@ is that it will fail if load is not > used, so it really should be baked into the interpreter. Otherwise there > are problems when distributing scripts. > > I quite like the simpler convention in kdb+, where an isolated / at the > start of a line starts a multiline comment, and an isolated \ terminates > it. However, this isn't much different from the Note ... ) convention in J. > > On Wed, May 9, 2018 at 6:46 AM, Ian Clark <[email protected]> wrote: > >> Cross-posted to programming forum at request of Chris Burke. >> Ian Clark >> >> ---------- Forwarded message ---------- >> From: Ian Clark <[email protected]> >> Date: Wed, May 9, 2018 at 10:35 AM >> Subject: Convention to stop loading a script >> To: [email protected] >> >> >> 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
