Mintoris Forum

Author Topic: fun with parse$  (Read 2125 times)


  • Sr. Member
  • ****
  • Posts: 146
fun with parse$
« on: Mar 01, 2013, 10:04 AM »
I recently noticed parse$. It allows executing data -- in this case a string -- that you may have previously manipulated. Certain other basics do this as does lisp, mumps, etc. This has some interesting uses. For one, given Chuck's excellent graphing routines, it is trivial to write a routine to plot a graph of any function of a single variable expressible in basic. See attached short program graph.bas.

Another routine -- parsetest.bas -- is attached.  You can use it to evaluate expressions that it prompts for. Suppose you are unsure of how some function or operator works (example: how are % and mod different). Without an interactive option in Basic, you would have to write a little test program and save it and run it (and if you made a mistake more than once). You can run parsetest in place of many test programs.

Built into parsetest are also some utility functions to demonstrate how you can write complete programs in strings that you parse. To function properly in these expressions you need value returning functions. Included are the functions set (to set numeric variables), sets (to set string variables), puts (to output a string), and when (which repeatedly parses an expression while it returns true). You can implement multiple program steps by concatenating function invocations with "+" (or "-" or "*"). Try "demo1()" and "demo2()" at the parsetest prompt. There is also a function -- factor(n) -- that shows how to implement recursive routines without blowing the stack. None of this is intended to be useful except to demonstrate the power of parse$.
« Last Edit: Mar 01, 2013, 03:00 PM by jclemens »


  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1899
Re: fun with parse$
« Reply #1 on: Mar 01, 2013, 11:56 PM »
The recursive method you used in factor() is exactly right and a very good example. I don't know of a way to fix the stack limitations on functions (subs that return a value). Basic's expression parser is recursive so there is a lot of stack overhead already. When you execute a user defined function inside an expression and that user function has expressions which cause further recursion, the stack gets full pretty fast. Subs that don't return a value and handle recursion by passing values by reference do not have the stack overhead and can go thousands of recursions deep.
« Last Edit: Mar 02, 2013, 12:08 AM by Chuck »