loops in fig

this is part 5 of an introductory series on fig programming. for part 4, go here. for the next part, go here.

 

part 5: loops in fig

 

this is really the first chapter about “program blocks.”

so far, weve covered one type of block– a snippet of inline python:

python
    y = (5 + 12) * 3  # 51; different than:
    y = 5  + 12  * 3  # 41; (order of ops)
fig

 

this block begins with the python command, and the end is marked with the fig command.

the defining characteristic of a block is probably that it starts and ends with a pair of commands.

in fig, you can end any block with the fig command. but semantically it makes the most sense when it ends a python block, because python means: “here is some python code” and fig means: “get back to the fig code.”

all loops are program blocks, also known as “command blocks.”

between the start and end of the loop blocks are the lines of code that will “loop.”

fig has three kinds of loop: for, while and forin.

the simplest loop is the while loop. lets make a single line of code to print a zero:

x  print

 

now lets start a while block by putting it on the line before the one we just wrote:

while
x  print

 

we need to mark the end of a loop, or fig will loop every line that comes after the while command:

while
x  print
fig

 

there is nothing wrong with this block; its perfectly formed. however, while blocks have their own end marker, which you can optionally use in place of the standard fig command. it does exactly the same thing, but helps note which block it ends:

while
x  print
wend

 

so you can end a while block using the fig command, or you can end it using wend (it stands for while-end.) the choice is up to you, they are interchangeable.

the while command exists in basic, python and even c. in basic and python, you can use while true: or while 1: to keep looping until the loop breaks with break or (in basic) exit while.

since for more than half a decade, ive used while 1 in python instead of worrying about setting up the loop with a condition, fig is designed this way for simplicity.

while
x  print
wend

 

prints 0 (or an array stored in x, where applicable) repeatedly until the user breaks with ctrl-c on the keyboard.

besides ctrl-c, the other way to break out of a while loop is using the break command (same as in python,) but without a conditional (covered in the next chapter) a break command will either prevent the loop itself, or prevent the lines inside it from running:

while
x  "this only runs once-- no loop"  print
break
wend

 

the break command stops the loop right after it runs the code inside it once, so it is as if the while command isnt there at all; only the line that prints.

while
break
x  "this line doesnt run at all"  print
wend

 

moving the break command to before the other line inside the loop exits before the lines after it can even run– so this entire block does nothing other than waste a tiny amount of time.

in order to make a while loop do something useful, you probably want to put the break command inside a conditional block. we will get to those in the next chapter.

a forin loop will loop through the items in an array, running the same code inside the block for each one. these items can be lines of a file, lines in a website, letters of a string, pieces of a string made into an array by split– any array.

lets do words in a string, by splitting the string into an array by spaces:

names "ady susan kerry morgan lori"  split names " "
forin p names
    now p  print
    fig

 

fig will split the string by ” ” to make an array called names, and print each one:

ady
susan
kerry
morgan
lori

 

we end the forin loop using fig again, but just as while has wend for (optional) semantic use, forin has nextin (or next). use whichever you prefer.

forin p names
    now p  print
    nextin

 

if you want to loop through numbers, you can use a for loop. a forin loop will run the same code repeatedly, once per array item– and a for loop once per number in a range– for has 4 parameters:

  • the variable for will set with the value of the current item (just like a forin loop)
  • the number to start with
  • the number to stop at
  • the “step”; the number to increase on each loop

 

in other words:

for v start stop step

 

suppose we want to bring variable size from 5 to 12, doing every whole number in that range:

for size  5 12 1
    now size  prints " " prints
    next

 

will output: 5 6 7 8 9 10 11 12

odd numbers from 33 to 17?

for s 33 17  -2
    now s  prints " " prints
    next

 

33 31 29 27 25 23 21 19 17

one quirk of python is that it insists on integer (whole number) steps in numeric ranges. in python (which is what fig translates its code to,) a for (range) loop isnt going to do a decimal step.

for v start stop step # step has to be integer
    now v  print
    next

 

however, if you use a constant for the step instead of a variable, fig will let you do a float step:

start 5
stop 10
for v start stop 2.5 # step is constant 2.5
    now v  prints " " prints
    next

 

outputs: 5.0 7.5 10.0

this builds a different kind of loop (actually a custom while loop) in the python translation, instead of a genuine for loop.

in the next chapter, while loops will become more useful when they can start and stop based on conditions. certainly you can use them anyway, in any situation where using ctrl-c on the keyboard to stop looping is suitable.

 

 

Advertisements

6 thoughts on “loops in fig

    1. i think: there is a fine example of why we should have access to the code that runs in our machines.

      im familiar with the arguments to the contrary. perhaps it should be illegal to drive a car youve changed factory firmware on until its been inspected, i have no idea how to make that work reasonably. but being able to examine it is crucial, imo. after all, you can take apart the rest of the car already (more or less.)

      specifically, i dont think those codes were made public– at least i couldnt find them.

      for what its worth, i have my own gnu/linux distro based on refracta: http://distrowatch.com/weekly.php?issue=20161017#refracta which along with the choice of license for my blog, probably make a number of biases obvious. its never a crime to ask for payment, though. i think we can do that without relying so heavily on either charity or monopoly, but im pro-economy. (having one helps.)

      Like

  1. What’s sad about the emissions testing is that they were relying on the digital components to be honest and not measuring the actual emissions of the car itself. Seems to me there could be made a simple device (for the inspection crew) that they attach to the exhaust and then drive around with it for the inspection, rather than relying on the built-in stuff. That way, it would be more universally applicable, and even cars with custom (or no) software could be tested.
    =======
    The for-loops are interesting. I like the fact that you provide different alternatives in fig. It’s funny how quirks like Python’s for-loop limitations come out when you think about converting to it. Same holds with strings. I almost forgot to ask: Is fig for Python 2 or 3?

    Liked by 1 person

    1. i prefer python 2 strings. they always do what i need. if you compare fig 2.9 (python 2) with fig 3.1, you will note all the trouble i went to trying to get strings to work the way i expect them to– ascii strings, utf-8, binary file strings.

      python 2 doesnt have those issues, and i knew an industry guy who says that he still prefers 2.x. the foundation will drop support in 2020, so i dunno if pypy (based on rpython) will keep it alive, or if it will get forked, but after half a year of trying out fig 3.1, fig 4.x goes back to python 2.

      short answer: there are fig versions for both, but the preferred and actively maintained one is for python 2.

      https://github.com/PLinux99/figos/blob/master/fig41.py

      Like

      1. “Official support” may end, but that doesn’t mean the language itself is “dead”. I imagine people will be using Python 2 for many, many years after support ends. There are already forks, so I don’t imagine fig will go obsolete any time soon. While I like some of the features of Python 3, I do agree that strings are easier in 2. I had to read some long articles about why the move to Python 3, and there are some interesting notes, though from what I read it boils down to uncovering silent bugs, esp. text bugs that were a problem for UTF-16 users in Asian countries. It makes me wonder if it would have been better to have left string purification up to the programmer.

        Liked by 1 person

        1. if there were a library for handling strings in a backwards-compatible way, import python2strings, that would be fine.

          if there were a library for handling utf-16 better, that would be ideal.

          if there were from __past__ import strings, great–

          ive known about this change pretty much since the year i taught myself python (thank you sugarlabs, and mr. downey) and ive watched it over the years. the fixes dont work, the translators dont work, and it never gets better. but of course im probably on the fringe of use cases anyway, or it would work fine. i mean, not the way i want to use it, but why should i care about that?

          Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s