Deferred evaluation of program object in SysRPL - Hewlett Packard

This is a discussion on Deferred evaluation of program object in SysRPL - Hewlett Packard ; In UserRPL, I have had occasion to write a program in this form: > main prog where I eventually roll unevaluates > onto first level of stack then EVAL >> What happens is that the program puts the object > ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Deferred evaluation of program object in SysRPL

  1. Deferred evaluation of program object in SysRPL

    In UserRPL, I have had occasion to write a program in this form:

    <<
    << subroutine >>
    main prog where I eventually roll unevaluates <> onto
    first level of stack then EVAL
    >>


    What happens is that the program puts the object <> after
    the program arguments, ROLL or ROT or ROLLD gets it up out of the way
    but still on the stack, some computations are done on the inputted
    arguments (there is an IF THEN ELSE structure here too that effects
    these manipulations), then <> is rolled back into position
    and EVAL is called to get it to act on the arguments in the stack
    levels above it.

    I would like to be able to do something similar in SysRPL, but
    the :: ; object limiters to no defer evaluation so this doesn't do
    what I want:

    ::
    :: subroutine ;
    main program
    ;

    In this case ::subroutine; gets evaluated (or an unsuccessful attempt
    is made to evaluate) right away. I have tried to enclose the
    subroutine in UserRPL delimiters x<< >>x, but that doesn't seem to
    defer evalution.

    I am gathering that the approach to calling internal subroutines or,
    for that matter, user programs outside of one program is different
    than UserRPL. For example, I have two programs BB and AA, and BB
    executes and uses output from AA. In UserRPL this works:

    << AA main program >>

    But in SysRPL this won't even compile since the AA label isn't
    recognized:

    :: AA main program ;

    I know I should really dive into Kalinowski and Dominik, and indeed I
    am, but I am finding that the reference works are so involved I am
    beginning to miss the wood for the trees.

    Greatful for direction.

    Les


  2. Re: Deferred evaluation of program object in SysRPL

    Hello,

    > ::
    > :: subroutine ;
    > main program
    > ;


    If you donīt want your program evaluated by the runstream place a
    single ' in front of it:
    ::
    '
    :: subroutine ;
    main program
    ;


    > But in SysRPL this won't even compile since the AA label isn't
    > recognized:
    >
    > :: AA main program ;

    In Sys-RPL you have to specify the object for the compiler. AA
    automatically compiles to ID AA by the command line compiler, aka
    parser. If you donīt specify the object in Sys_RPL the compiler treats
    it as a NULLNAME for a lib.

    Dive into Part I HP49 Objects. That will explain a lot concerning your
    questions.

    I suggest to read "Programming in System RPL" at least once in a
    whole. Some things wonīt make sense at the beginning but after a while
    everthing links together ;-)

    Greetings
    Andreas
    http://www.software49g.gmxhome.de.



  3. Re: Deferred evaluation of program object in SysRPL

    The ' token works fine--thank you.

    I will try to digest the whole book, but it is a 600 page monstrosity.
    Fortunately, almost all of that is tables and indices.

    The good thing about SysRPL is that you don't have to master all of it
    to start writing useful programs.

    Les

    P.S. Please take a peek at my other thread on complex number
    arithmetic. Is it not peculiar indeed that there seem to be no
    commands in HP49 SysRPL for basic complex number functions, whereas at
    least there are unsupported entries in HP48 SysRPL? I have a rather
    slow little UserRPL program that computes the sine and cosine
    integrals by complex continued fraction, and I was hoping to translate
    it to SysRPL that relies little to none on UserRPL commands. Looks
    like a major rewrite, especially if I want to use extended numbers
    (which I do!)


  4. Re: Deferred evaluation of program object in SysRPL

    Iīll answer in that tread.
    Andreas


  5. Re: Deferred evaluation of program object in SysRPL


    > I will try to digest the whole book, but it is a 600 page monstrosity.
    > Fortunately, almost all of that is tables and indices.
    >
    > The good thing about SysRPL is that you don't have to master all of it
    > to start writing useful programs.

    Yupp, but reading the wohle book a couple times gives you a good
    overview where to search for your answers. And it is not really that
    much text.

    > I have a rather
    > slow little UserRPL program that computes the sine and cosine
    > integrals by complex continued fraction, and I was hoping to translate
    > it to SysRPL that relies little to none on UserRPL commands.

    The slowness comes from the error-checking, not from the calculation.
    So even if you calculate it the same way it is done in the ROM you
    will notice a significant speed enhancement.

    Andreas



  6. Re: Deferred evaluation of program object in SysRPL

    In article <1182126152.454919.149360@u2g2000hsc.googlegroups.c om>,
    lcw1964 wrote:
    >In UserRPL, I have had occasion to write a program in this form:
    >
    ><<
    > << subroutine >>
    >main prog where I eventually roll unevaluates <> onto
    >first level of stack then EVAL
    >>>

    >
    >What happens is that the program puts the object <> after
    >the program arguments, ROLL or ROT or ROLLD gets it up out of the way
    >but still on the stack, some computations are done on the inputted
    >arguments (there is an IF THEN ELSE structure here too that effects
    >these manipulations), then <> is rolled back into position
    >and EVAL is called to get it to act on the arguments in the stack
    >levels above it.
    >
    >I would like to be able to do something similar in SysRPL, but
    >the :: ; object limiters to no defer evaluation so this doesn't do
    >what I want:
    >
    >::
    > :: subroutine ;
    > main program
    >;
    >
    >In this case ::subroutine; gets evaluated (or an unsuccessful attempt
    >is made to evaluate) right away. I have tried to enclose the
    >subroutine in UserRPL delimiters x<< >>x, but that doesn't seem to
    >defer evalution.


    This question has been answered elsewhere in this thread, but I asked a
    similar question a few years ago that resulted in a discussion that
    might be useful to you:

    http://groups.google.com/group/comp....66c16fa667a31c

    -Mike
    --
    http://www.mschaef.com

  7. Re: Deferred evaluation of program object in SysRPL

    On Sun, 17 Jun 2007 22:12:26 -0500:

    > I will try to digest the whole [SysRPL] book,
    > but it is a 600 page monstrosity.


    How many have ever used one of those laminated "reference" cards,
    which condense an entire subject into one single card?

    Here's one for SysRPL, by Mika Heiskanen
    (type VER on HP50/49G[+] to see his name again):
    http://www.hpcalc.org/search.php?query=ent_srt

    For a basic introductory course (prerequisite to above):
    http://www.hpcalc.org/search.php?query=rplman

    [r->] [OFF]

+ Reply to Thread