Re: extending FEM enginering package with Guile

[Paul Jarc]

Mario Storti <address@hidden> wrote:
> the lack of `break' and `continue' in Scheme.

Guile has break and continue (undocumented in the 1.6.4 manual ), but
they are only defined inside the body of the while loop, not at the
top level.  (Well, there is a break procedure from srfi-1, but that
does something different.)

continue seems to be buggy in 1.6.4:
guile> (define x 1)
guile> (while (< x 5)
...      (format #t "x1=~A\n" x)
...      (if (= x 3)
...        (begin
...          (set! x 9)
...          (continue)
...          (format #t "x2=~A\n" x)))
...      (set! x (1+ x)))
x1=1
x1=2
x1=3
x2=9
#t
guile> (format #t "x=~A\n" x)
x=10

But it's fixed in 1.7 CVS.

> Question 2: I have learned that in Scheme it is considered bad
> practice to `set!' variables, or in general to use side-effects. In
> our applications we manipulate huge structures (mainly vectors, sparse
> matrices, graphs, with sizes in the order of several hundredths MBs,
> and running for weeks), and it seems much more efficient to code this way
> (using side-effects). Am I right?

Side effects are discouraged by functional programmers because lots of
bugs are the result of modifying (by side-effect) the wrong object by
mistake.  (Of course, these bugs are not totally eliminated by
avoiding side effects: essentially the same thing can happen by
shadowing an existing binding, with "define" at the top level, or in
let*.)  Well-written functional code may also be easier to read and
understand than procedural code, which also helps to eliminate bugs.

To see which way is more efficient, profile the code both ways.  If
performance matters, and if side-effect code is found to be faster,
and if you're willing to put as much effort into debugging your
side-effect-using Scheme code that you would have to put into
debugging your side-effect-using C code, then go ahead and use side
effects.


paul