Loading ...
Sorry, an error occurred while loading the content.

RE: [Clip] Feature proposal

Expand Messages
  • John Shotsky
    So, I implemented this method in a new clip section I m writing, currectly at a little over 600 lines. (Thanks, Art!) I have two subroutines, each with around
    Message 1 of 14 , Jul 30 6:46 AM
    • 0 Attachment
      So, I implemented this method in a new clip section I'm writing, currectly at a little over 600 lines. (Thanks, Art!) I
      have two subroutines, each with around 25 lines. There are 4 tests at the top to decide which branch to take. It works
      as a call/return should work, but with a limitation that it is difficult to come up with unique return tag names. I have
      taken to writing each return tag name near the return segment, so that I can see what the last one was.

      For example, CaseChanger is one of my subroutines. At the end of that subroutine, in comments, I have
      ;CaseChanger1
      ;CaseChanger2
      ;CaseChanger3
      ^!Goto ^%Return%
      Showing that it is in use 3 times, and advising me what the next usage should use for a tag name. That is a little
      inconvenient, but it works.

      In just one day of using this, it became clear that I could write several other segments of this code as subroutines,
      even when only used once. By placing these units of code out of the inline process, it is easier to follow the logic of
      the program, even swapping order quickly and easily, simply by switching three lines at the 'call' point. My branches at
      the top can become tests, and if true, do subroutine 2, then return. Suddenly, all the inline code becomes a set of
      modules and the order of things becomes very clear. It is evident that recursion could be accomplished with a little
      more effort, but it would get tricky, whereas a true subroutine feature would probably permit nested calls easily. (As
      long as there is a stack for return addresses.)

      That makes me want 'real' subroutines even more than before, so that I can further clean up what are now very
      complicated, very long processes. Most of the time, a clip section starts at the top, processes through to the bottom,
      then exits. Hierarchy is used extensively to divide things up. Subroutine logic would permit an entery at the top,
      followed by a number of calls to subroutines, then an exit, while the logic of the section would be exposed clearly.

      Regards,
      John
      RecipeTools Web Site: <http://recipetools.gotdns.com/> http://recipetools.gotdns.com/

      From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of Art Kocsis
      Sent: Sunday, July 29, 2012 09:18
      To: NoteTab-Clips
      Subject: RE: [Clip] Feature proposal


      At 7/29/2012 06:17 AM, John wrote:
      >To clarify this issue, let's say that there are 10 ways to get through one
      >clip section.

      I agree that it would be nice to have subroutines. Much better to have
      subroutines with argument lists!

      For the simple subroutines that you are describing have you tried this.
      It is a little kludgy but it really only adds one line of code and one
      address per call.

      ^!Set %Rtn%=P1
      ^!Goto Sub
      :P1
      ^!Info Now At P1

      ^!Set %Rtn%=P2
      ^!Goto Sub
      :P2
      ^!Info Now At P2

      ^!Set %Rtn%=P3
      ^!Goto Sub
      :P3
      ^!Info Now At P3

      ^!Goto End

      :Sub
      ^!Info Now At Sub
      ^!Goto ^%Rtn%

      HTH, Art



      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.