extending FEM enginering package with Guile

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: mstorti@intec.unl.edu.ar
http://www.cimec.org.ar/mstorti, http://www.cimec.org.ar
-------------------------



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: extending FEM enginering package with Guile

[Paul Jarc]

Mario Storti <mstorti@intec.unl.edu.ar> 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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: extending FEM enginering package with Guile

[Ken Anderson]

One big advantage you get with Scheme that you don't get with Python, ...
is that you can easily tailor a language to better fit your library.  For a description of this, see the experience we've had with using Java libraries in JScheme:
http://ll2.ai.mit.edu/talks/bbnll2/bamby/title.html

I'm an old seismologist who did fortran and C until i found Common Lisp.
Using Guile, you might have a profound impact on your field.

k

At 04:20 PM 1/5/2004 -0300, Mario Storti wrote:

>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: mstorti@intec.unl.edu.ar
>http://www.cimec.org.ar/mstorti, http://www.cimec.org.ar
>-------------------------
>
>
>
>_______________________________________________
>Guile-user mailing list
>Guile-user@gnu.org
>http://mail.gnu.org/mailman/listinfo/guile-user



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: extending FEM enginering package with Guile

[rm]

On Mon, Jan 05, 2004 at 04:20:17PM -0300, Mario Storti wrote:
> 
>
> [...]                       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++

Well, scheme has a rather powerfull syntax facility, you can (and probably
should) write syntactic extensions that match your users needs/expectations.
With the help of macros (esp syntax-case e.a.) you can create your domain
specific "little language". After all, this is one of the reasons why
the FSF did choose scheme as their future embedable scripting language.

> 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:

Flame wars aside, if there is a need for such a syntax it can be implemented.
Heinrich Taube (of Common Lisp Music fame) wrote a guile version of Common
Lisp's loop macro -- i think i once hacked up a guile module wrapper for it.
With that code you can do things like:

 (use-modules (clm iter))

 (define (all-squares-upto number)
   (loop for n in (iota number)
         collect (* n n)))

 (loop for language in '(perl python java cobol)
       do (format #f "~A sucks!" language))

 ;; break out of a loop
 (loop while (= (remainder (current-time ) 2) 0)
       do (format #t "Not yet ~%"))

 
etc. etc.
If you want i can try to find my wrapper and put it online.

 Ralf Mattes
> 
> 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: mstorti@intec.unl.edu.ar
> http://www.cimec.org.ar/mstorti, http://www.cimec.org.ar
> -------------------------
> 
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: extending FEM enginering package with Guile

[Mario Storti]

>>>>> On Mon, 05 Jan 2004 16:20:17 -0300, 
>>>>>      Mario Storti <mstorti@intec.unl.edu.ar> said:

> 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
> ...

Thanks to all answering my posting. 

>>>>> On Mon, 05 Jan 2004 15:26:09 -0500, 
>>>>>      prj@po.cwru.edu (Paul Jarc) said:

> Mario Storti <mstorti@intec.unl.edu.ar> 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.)

OK. That seems to be what I expected. I couldn't get `continue' and
`break' working in 1.6.4 and I couldn't compile 1.7.0 (errors in
configure about the GMP library). Then I have taken the `while'
definition from `boot-9.scm' in 1.7.0 and inserted it directly in my
code (with a minor modification, since `make-symbol' is not available
in 1.6.4.). So I have now a working `while-continue-break' macro. This
is a warkaround until a new stable release comes out. 

>>>>> On Mon, 5 Jan 2004 23:04:14 +0100, 
>>>>>      rm@fabula.de said:

> Well, scheme has a rather powerfull syntax facility, you can (and probably
> should) write syntactic extensions that match your users needs/expectations.
> With the help of macros (esp syntax-case e.a.) you can create your domain
> specific "little language". After all, this is one of the reasons why
> the FSF did choose scheme as their future embedable scripting language.

>> 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:

Yes, I see that very powerful macros can be written. 

> Well, scheme has a rather powerfull syntax facility, you can (and probably
> should) write syntactic extensions that match your users needs/expectations.
> With the help of macros (esp syntax-case e.a.) you can create your domain
> specific "little language". After all, this is one of the reasons why
> the FSF did choose scheme as their future embedable scripting language.

> Flame wars aside, if there is a need for such a syntax it can be implemented.
> Heinrich Taube (of Common Lisp Music fame) wrote a guile version of Common
> Lisp's loop macro -- i think i once hacked up a guile module wrapper for it.
> With that code you can do things like:

>  (use-modules (clm iter))

>  (define (all-squares-upto number)
>    (loop for n in (iota number)
>          collect (* n n)))

>  (loop for language in '(perl python java cobol)
>        do (format #f "~A sucks!" language))

>  ;; break out of a loop
>  (loop while (= (remainder (current-time ) 2) 0)
>        do (format #t "Not yet ~%"))
> etc. etc.
> If you want i can try to find my wrapper and put it online.

>  Ralf Mattes

Thanks. I think that with the `while-continue-break' to be included in
next releases is enough. 

Mario

-------------------------
Mario Alberto Storti
CIMEC (INTEC/CONICET-UNL), Guemes 3450 - 3000 Santa Fe, Argentina
Tel/Fax: +54-342-4511594 e-mail: mstorti@intec.unl.edu.ar
http://www.cimec.org.ar/mstorti, http://www.cimec.org.ar
-------------------------


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: extending FEM enginering package with Guile

[Kevin Ryde]

Mario Storti <mstorti@intec.unl.edu.ar> writes:
>
> So I have now a working `while-continue-break' macro. This
> is a warkaround until a new stable release comes out. 

There are no plans to change `while' in the 1.6 branch.  Certainly
continue is broken, but it wasn't documented, so doesn't really
qualify for a bug fix.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: extending FEM enginering package with Guile

[Keith Wright]

> From: Mario Storti <mstorti@intec.unl.edu.ar>
> 
> .... 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, 

Don't loop, recursion is easier.  Don't believe it?  Look in
your math books.  You may find recursion, often called induction,
but mathemeticians never loop.  They don't have to, so they do
it the easy way.

> or call/cc's is an overkill.

Definitely stay away from call/cc.  It _is_ hard, and the Guile
implementation may be buggy.  (Was in version 4, and nobody
knew how to fix it.  I haven't tested version 6 for this.)

> I'm not speculating here, I have talked with many of them
> (those with better programming skills).

You asked if they could understand recursion, and they
said "No"?

> Perhaps such things may be used by the developers, but definitely
> not by the average user.

Everybody uses recursion in Scheme.

> 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.

Don't use while in the first place.  Use "named LET".  Then BREAK
is just computing the final answer, and "continue" is calling 
the named LET procedure.

> I think that one can do that with catch/throw but it also seems
> an overkill.

And ugly and stupid.  Besides, Scheme doesn't have catch/throw
(it's added in Guile and maybe some other implementations).

> 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. 

(let loop ([var1 init1]
           [var2 init2])
  (if (cond1) (compute answer))
  ; ...
  (if (cond2) (loop (new-var1) (new-var2)))
  ; ...
  (loop (new-var1) (new-var2))  ; end-of-loop = continue
)

> 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?

It depends on what the side effects are.  If, in the middle of
inverting a matrix, you start dorking around with the values of
unrelated global variables you are probably messing up.

Just compute your inverse (or whatever) and return it as the answer.
Do not find or make some global variable to SET! to the answer.

On the other hand, to compute your final answer you may want
to allocate a big vector (matrix, graph) full of zeroes (say)
as a local variable and compute the result by repeatedly
updating elements.  When your procedure returns the answer
the local variables disappear, only the result is returned,
and nobody need know about the VECTOR-SET! you did inside
your procedure.

     -- Keith


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: extending FEM enginering package with Guile

[Paul Jarc]

Keith Wright <kwright@free-comp-shop.com> wrote:
> Don't use while in the first place.  Use "named LET".  Then BREAK
> is just computing the final answer, and "continue" is calling
> the named LET procedure.

Only if the final answer (or call to the named let) appears in tail
position.

> (let loop ([var1 init1]
>            [var2 init2])
>   (if (cond1) (compute answer))
>   ; ...
>   (if (cond2) (loop (new-var1) (new-var2)))
>   ; ...
>   (loop (new-var1) (new-var2))  ; end-of-loop = continue
> )

This is an infinite loop.  Maybe you meant:

(let loop ((var1 init1)
           (var2 init2))
  (cond
   ((cond1) (compute answer))
   ((cond2) (loop (new-var1) (new-var2)))
   (else    (loop (new-var1) (new-var2)))))

I'm not sure what you mean by your "end-of-loop = continue" comment.
If you mean that falling through to the end of the let body will
result in another loop iteration, then that's wrong.  If you mean that
an explicit call to loop will result in another loop iteration, then
that's right.  But if anything appears after it - i.e., if it's not in
tail position - then the result of the inner call won't be passed back
as the result of the outer computation.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: extending FEM enginering package with Guile

[Keith Wright]

> From: prj@po.cwru.edu (Paul Jarc)
> 
> Keith Wright <kwright@free-comp-shop.com> wrote:
> > Don't use while in the first place.  Use "named LET".  Then BREAK
> > is just computing the final answer, and "continue" is calling
> > the named LET procedure.
> 
> Only if the final answer (or call to the named let) appears in tail
> position.
> 
> > (let loop ([var1 init1]
> >            [var2 init2])
> >   (if (cond1) (compute answer))
> >   ; ...
> >   (if (cond2) (loop (new-var1) (new-var2)))
> >   ; ...
> >   (loop (new-var1) (new-var2))  ; end-of-loop = continue
> > )
> 
> This is an infinite loop.  Maybe you meant:
> 
> (let loop ((var1 init1)
>            (var2 init2))
>   (cond
>    ((cond1) (compute answer))
>    ((cond2) (loop (new-var1) (new-var2)))
>    (else    (loop (new-var1) (new-var2)))))

Ooops!  Yes, that's what I meant.  I meant it so much that I
had written a reply claiming that it is the same as what I said
before I noticed the difference.  All the IF's in my program
should have BEGIN's in the else part that contain all following
code.

> I'm not sure what you mean by your "end-of-loop = continue" comment.

I meant that a WHILE loop may have CONTINUE at the end without
changing the meaning, because the bottom of the loop is an implicit
continue.  With named LET you must explicitly write that CONTINUE,
because it does not continue to loop when it hits the bottom.
("Bottom" is a better word than "end" for that point in the code,
because "end" could be taken to mean "finish of execution").

> If you mean that falling through to the end of the let body will
> result in another loop iteration, then that's wrong.

I meant the exact opposite of that wrong statement.

    -- Keith


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: extending FEM enginering package with Guile

[Keith Wright]

Sorry if this is a repeat, I tried to send before, but I
haven't seen it on the list.

> From: prj@po.cwru.edu (Paul Jarc)
> 
> Keith Wright <kwright@free-comp-shop.com> wrote:
> > Don't use while in the first place.  Use "named LET".  Then BREAK
> > is just computing the final answer, and "continue" is calling
> > the named LET procedure.
> 
> Only if the final answer (or call to the named let) appears in tail
> position.
> 
> > (let loop ([var1 init1]
> >            [var2 init2])
> >   (if (cond1) (compute answer))
> >   ; ...
> >   (if (cond2) (loop (new-var1) (new-var2)))
> >   ; ...
> >   (loop (new-var1) (new-var2))  ; end-of-loop = continue
> > )
> 
> This is an infinite loop.  Maybe you meant:
> 
> (let loop ((var1 init1)
>            (var2 init2))
>   (cond
>    ((cond1) (compute answer))
>    ((cond2) (loop (new-var1) (new-var2)))
>    (else    (loop (new-var1) (new-var2)))))

Ooops!  Yes, that's what I meant.  I meant it so much that I
had written a reply claiming that it is the same as what I said
before I noticed the difference.  All the IF's in my program
should have BEGIN's in the else part that contain all following
code.

> I'm not sure what you mean by your "end-of-loop = continue" comment.

I meant that a WHILE loop may have CONTINUE at the end without
changing the meaning, because the bottom of the loop is an implicit
continue.  With named LET you must explicitly write that CONTINUE,
because it does not continue to loop when it hits the bottom.
("Bottom" is a better word than "end" for that point in the code,
because "end" could be taken to mean "finish of execution").

> If you mean that falling through to the end of the let body will
> result in another loop iteration, then that's wrong.

I meant the exact opposite of that wrong statement.

    -- Keith



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user