skill writing style

It doesn't matter which style you pick because they are completely equivalent. For example:

code='(x=5)
code => (x = 5)
car(code) => setq
cadr(code) => x
sstatus(printinfix nil)
code => (setq x 5)
sstatus(printinfix t)

So what you can see from the simple example above is that the parser will cope with either the C (or "infix") style of expression or the LISP style of expression, but actually it really represents it in a LISP format. Since the only difference is at parsing time, there's no efficiency difference between the two styles; they both execute in the same way.

The sstatus(printinfix t/nil) is a way of getting the pretty printer to output in C or LISP styles. So if you've written a function, such as this:

(procedure (abExtendBBox bbox @rest xy)
  (let (minx maxx miny maxy coord)
       (if (and (listp xy)
                (listp (car xy))
                (listp (car (car xy))))
           (setq xy (car xy)))
       (if (null bbox)
           (setq bbox (list (car xy) (car xy))))
       (setq minx (xCoord (lowerLeft bbox)))
       (setq maxx (xCoord (upperRight bbox)))
       (setq miny (yCoord (lowerLeft bbox)))
       (setq maxy (yCoord (upperRight bbox)))
       (foreach coord xy
                (if (lessp (xCoord coord) minx) (setq minx (xCoord coord)))
                (if (lessp (yCoord coord) miny) (setq miny (yCoord coord)))
                (if (greaterp (xCoord coord) maxx) (setq maxx (xCoord coord)))
                (if (greaterp (yCoord coord) maxy) (setq maxy (yCoord coord))))
       /* return the new bbox */
       (list (list minx miny) (list maxx maxy))))

You can define this function and then do:

pp(abExtendBBox)

 procedure(abExtendBBox(bbox \@rest xy)
    let((minx maxx miny maxy coord)
        if((listp(xy) && listp(car(xy)) && listp(car(car(xy))))
            (xy = car(xy))
        )
        if(!bbox
            (bbox = list(car(xy)
                    car(xy)
                ))
        )
        (minx = (xCoord
                (lowerLeft bbox)
            ))
        (maxx = (xCoord
                (upperRight bbox)
            ))
        (miny = (yCoord
                (lowerLeft bbox)
            ))
        (maxy = (yCoord
                (upperRight bbox)
            ))
        foreach(coord xy
            if(((xCoord coord) < minx)
                (minx = (xCoord coord))
            )
            if(((yCoord coord) < miny)
                (miny = (yCoord coord))
            )
            if(((xCoord coord) > maxx)
                (maxx = (xCoord coord))
            )
            if(((yCoord coord) > maxy)
                (maxy = (yCoord coord))
            )
        )
        list(list(minx miny)
            list(maxx maxy)
        )
    )
)

It will turn it back into C-style. Or you can do sstatus(printinfix nil) before pp-ing a function, and it will dump it in LISP-style.

Now, why do I write it in LISP-style (usually) rather than C-style? Well, when I first starting writing SKILL code in (about) 1991, I had written in a lot of languages previously (including C, and a little LISP). I found that if I used the C-style, I kept making mistakes because it wasn't quite C. Also, it is fussier about whitespace with C-style, whereas additional spaces don't matter with LISP style. Secondly, I found that it encouraged me to think in terms of LISP ways of doing things - i.e. thinking in terms of lists rather than arrays, and so on.

So my natural inclination after all these years is to write in LISP style. However, if I'm writing a function as an example to be taken and modified (rather than just used verbatim), then I usually write it in C style because that's what is most commonly used. My usage of LISP style is a bit pedantic - so for example, I would write (setq a (times (difference b c) d)) whereas I have colleagues who would happily throw (setq a (b-c)*d) into their code. For me it's all or nothing...

My general recommendation is to pick a style that works for you, and stick with it. Don't mix and match the styles within the same code because that makes it very hard to read.

Regards,

Andrew. 

It doesn't matter which style you pick because they are completely equivalent. For example:

code='(x=5)
code => (x = 5)
car(code) => setq
cadr(code) => x
sstatus(printinfix nil)
code => (setq x 5)
sstatus(printinfix t)

So what you can see from the simple example above is that the parser will cope with either the C (or "infix") style of expression or the LISP style of expression, but actually it really represents it in a LISP format. Since the only difference is at parsing time, there's no efficiency difference between the two styles; they both execute in the same way.

The sstatus(printinfix t/nil) is a way of getting the pretty printer to output in C or LISP styles. So if you've written a function, such as this:

(procedure (abExtendBBox bbox @rest xy)
  (let (minx maxx miny maxy coord)
       (if (and (listp xy)
                (listp (car xy))
                (listp (car (car xy))))
           (setq xy (car xy)))
       (if (null bbox)
           (setq bbox (list (car xy) (car xy))))
       (setq minx (xCoord (lowerLeft bbox)))
       (setq maxx (xCoord (upperRight bbox)))
       (setq miny (yCoord (lowerLeft bbox)))
       (setq maxy (yCoord (upperRight bbox)))
       (foreach coord xy
                (if (lessp (xCoord coord) minx) (setq minx (xCoord coord)))
                (if (lessp (yCoord coord) miny) (setq miny (yCoord coord)))
                (if (greaterp (xCoord coord) maxx) (setq maxx (xCoord coord)))
                (if (greaterp (yCoord coord) maxy) (setq maxy (yCoord coord))))
       /* return the new bbox */
       (list (list minx miny) (list maxx maxy))))

You can define this function and then do:

pp(abExtendBBox)

 procedure(abExtendBBox(bbox \@rest xy)
    let((minx maxx miny maxy coord)
        if((listp(xy) && listp(car(xy)) && listp(car(car(xy))))
            (xy = car(xy))
        )
        if(!bbox
            (bbox = list(car(xy)
                    car(xy)
                ))
        )
        (minx = (xCoord
                (lowerLeft bbox)
            ))
        (maxx = (xCoord
                (upperRight bbox)
            ))
        (miny = (yCoord
                (lowerLeft bbox)
            ))
        (maxy = (yCoord
                (upperRight bbox)
            ))
        foreach(coord xy
            if(((xCoord coord) < minx)
                (minx = (xCoord coord))
            )
            if(((yCoord coord) < miny)
                (miny = (yCoord coord))
            )
            if(((xCoord coord) > maxx)
                (maxx = (xCoord coord))
            )
            if(((yCoord coord) > maxy)
                (maxy = (yCoord coord))
            )
        )
        list(list(minx miny)
            list(maxx maxy)
        )
    )
)

It will turn it back into C-style. Or you can do sstatus(printinfix nil) before pp-ing a function, and it will dump it in LISP-style.

Now, why do I write it in LISP-style (usually) rather than C-style? Well, when I first starting writing SKILL code in (about) 1991, I had written in a lot of languages previously (including C, and a little LISP). I found that if I used the C-style, I kept making mistakes because it wasn't quite C. Also, it is fussier about whitespace with C-style, whereas additional spaces don't matter with LISP style. Secondly, I found that it encouraged me to think in terms of LISP ways of doing things - i.e. thinking in terms of lists rather than arrays, and so on.

So my natural inclination after all these years is to write in LISP style. However, if I'm writing a function as an example to be taken and modified (rather than just used verbatim), then I usually write it in C style because that's what is most commonly used. My usage of LISP style is a bit pedantic - so for example, I would write (setq a (times (difference b c) d)) whereas I have colleagues who would happily throw (setq a (b-c)*d) into their code. For me it's all or nothing...

My general recommendation is to pick a style that works for you, and stick with it. Don't mix and match the styles within the same code because that makes it very hard to read.

Regards,

Andrew.