extending FEM enginering package with Guile

[Mario Storti]

Hi all,

I'm discovering Guile, and I found it very exciting. I'm writing a GPL
C++ Finite Element code (see http://venus.ceride.gov.ar/petscfem
http://venus.ceride.gov.ar/twiki/bin/view/Cimec/PETScFEMResults
http://venus.ceride.gov.ar/~mstorti/AHMED/tex/ahmed/node27.html ) and
at a certain point I found need of a scripting language.  Basically it
is an engineering code used for numerical simulations. The code runs
in parallel on Beowulf clusters using MPI/PETSc (
http://www.mcs.anl.gov/mpich , http://www.mcs.anl.gov/petsc/ ).  I
considered several choices: Perl, Python, Octave, Guile and other
Lisp-like languages. After evaluating the pros and cons, I'm now 90%
decided to choose Guile. 

The main pros of Guile are 

* It is the extension language of the GNU Project
* In my tests so far I had little difficulty (w.r.t. Perl, for
      instance) in writing wrappers for the PETSc library, even if I
      am more proficient with Perl. 

The cons are

* I think it will be harder for users to learn Scheme (than
  Perl/Python for instance) (this is the main con) [1]
* I didn't found any parallel implementations for Scheme. For GNU
  Common Lisp I found http://www.ccs.neu.edu/home/gene/pargcl.html
  I'm not able at this moment to assess the difficulty of doing this
  task. (Perhaps it's trivial). 

Right now, I have some very simple code wrapper for some PETSc
functions, and so far I found relatively easy to add
functions. Congratulations to the Guile developers!!

Coming back to [1], I have to say that the intended audience are
mainly engineers/physicists (I'm a physicist) whose programming skills
are in Fortran, Matlab and perhaps C/C++. Some of them (very few
indeed) know some Lisp from using AutoCAD. I know myself some Lisp
from using Emacs, and I have learned some Scheme in recent times (with
the scope of this extension project). 

The intended usage for the users is rather basic, setting
configuration variables, or some basic control of program execution. I
think that for these simple tasks most users will not have problems in
learning a new syntax ("I-have-to-learn-yet=another-syntax" :-( ). And
they win because they learn a new language that can be used for many
other things. I agree there. But there is one point which I find too
hard, and is the looping constructs. I think that explaining to the
users concepts like tail-call recursion, or call/cc's is an
overkill. I'm not speculating here, I have talked with many of them
(those with better programming skills).  Perhaps such things may be
used by the developers, but definitely not by the average user. There
is the `while' special form, but even with this some simple looping
constructs, like the following in C/C++

while (cond0) {
      // body1 0;
      // ...
      if (cond1) break;
      // body 1
      // ...
      if (cond2) continue;
      // body 2
      // ...      
}

are hard to write, due to the lack of `break' and `continue' in
Scheme. I think that one can do that with catch/throw bu it also seems
an overkill. I found some flame wars between some other Lisp dialects
and Scheme and I anticipate that I'm not interested in starting such a
discussion. So:

Question 1: I ask simply if there is some simple way of writing code
like this previous one in Scheme. 

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?

Question 3: Does anyone knows of some previous development regarding
Guile/Scheme in a parallel environment? (I mean using message
passing). 

Best regards,

Mario

-------------------------
Mario Alberto Storti
Centro Internacional de Metodos Computacionales
  en Ingenieria - CIMEC (INTEC/CONICET-UNL)
INTEC, Guemes 3450 - 3000 Santa Fe, Argentina
Tel/Fax: +54-342-4511594
e-mail: address@hidden
http://www.cimec.org.ar/mstorti, http://www.cimec.org.ar
-------------------------