guile-devel
[Top][All Lists]

## Re: I wrote fluid advection code: How to make this more elegant?

 From: Nala Ginrut Subject: Re: I wrote fluid advection code: How to make this more elegant? Date: Mon, 25 Jan 2016 01:21:17 +0800

```The math formula may take advantage of sweet expression which is
contained in the current Guile reader, IIRC.
One may give it a try?

On Sat, 2016-01-23 at 13:42 +0100, Taylan Ulrich Bayırlı/Kammer wrote:
>
> > Hi,
> >
> > I just recreated a fluid advection exercise in Guile Scheme and I’m not
> > quite happy with its readability. Can you help me improve it?
> >
> > My main gripe is that the math does not look instantly accessible.
> >
> > The original version was in Python:
> >
> >     psi[i] - c1*(psi[i+1] - psi[i-1]) + c2*(psi[i+1] - 2.0*psi[i] +
> > psi[i-1])
> >
> > My port to Scheme looks like this:
> >
> >     (let ((newvalue (+ (- (psir i)
> >                           (* c1 (- (psir (+ i 1)) (psir (- i 1)))))
> >                        (* c2 (+ (- (psir (+ i 1)) (* 2 (psir i)))
> >                                 (psir (- i 1)))))))
> >       (array-set! psinew newvalue i))
>
> Guile supports SRFI-105, so that could be:
>
>     {{psi[i] - {c1 * {psi[{i + 1}] - psi[{i - 1}]}}} + {c2 * {{psi[{i + 1}] -
> {2 * psi[i]}} + psi[{i - 1}]}}}
>
> which is less readable than the Python version because there's no
> first-hand support for operator precedence so we {} group all binary
> operations, plus we need to use {} within [], plus we must separate
> operators with whitespace, but maybe it's acceptable.
>
> You can put "#!curly-infix" at the start of your Scheme file to enable
> SRFI-105 syntax.
>
> Note that all those 'psi[x]' expressions will expand to
>
>     (\$bracket-apply\$ psi x)
>
> and you can implement a macro of that name to turn that into whatever is
> suitable at compile-time.  (If performance is not an issue, SRFI-123
> provides a run-time polymorphic procedure for \$bracket-access\$.)
>
> With a smart definition of \$bracket-apply\$, you could also cut down
> those psi[{i + 1}] to psi[i + 1].  The latter will expand to
>
>     (\$bracket-apply\$ psi i + 1)
>
> which could be accommodated for in a special-purpose definition of
> \$bracket-apply\$ such as:
>
>     (syntax-rules ()
>       ((_ obj index)
>        (obj index))
>       ((_ obj x operator y)
>        (obj (operator x y))))
>
> That would *not* support e.g. psi[i + j - 1], which would instead need
> to be written e.g. psi[{i + j} - 1], i.e. we only save one pair of {},
> but maybe that's good enough.
>
> By the way, e.g. {x - y + z} will turn into (\$nfx\$ x - y + z), and maybe
> there's a definition for \$nfx\$ out in the wild (or you can create one)
> that does operator precedence.  (That could then also be used in
> \$bracket-apply\$.)  So optimally, the whole thing could become:
>
>     {psi[i] - c1 * {psi[i + 1] - psi[i - 1]} + c2 * {psi[i + 1] - 2 * psi[i]
> + psi[i - 1]}}
>
> Taylan
>

```