[PATCH] minor fix in configure.ac

[Qian Yun]

I'll be honest, this one is spotted by gemini-3
(while gemini-2.5 fails to find it.)

- Best,
- Qian

diff --git a/configure.ac b/configure.ac
index ed30f25e..89b58703 100644
--- a/configure.ac
+++ b/configure.ac
@@ -44,7 +44,7 @@ if echo "$fricas_pwd" | grep ' ' ; then
AC_MSG_WARN([and name of build directory does not contain spaces.])
AC_MSG_ERROR([Name of build directory contains space.])
fi
-if echo "$srcdir" | grep ' ' || echo "fricas_top_srcdir" | grep ' ' ; then
+if echo "$srcdir" | grep ' ' || echo "$fricas_top_srcdir" | grep ' ' ; then
AC_MSG_WARN([Please make sure that name of source directory])
AC_MSG_WARN([and name of build directory does not contain spaces.])
AC_MSG_ERROR([Name of source directory contains space.])

[Qian Yun]

Another minor thing: the output redirection totally
defeats the purpose of "tee".

- Qian


diff --git a/Makefile.in b/Makefile.in
index 566dd035..275451e5 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -45,7 +45,7 @@ all-contrib: all-src
cd contrib/emacs && ${MAKE}

all-ax: all-src
- @echo finished system build on `date` | tee >lastBuildDate
+ @echo finished system build on `date` | tee lastBuildDate

all-src: stamp-rootdirs @fricas_all_prerequisites@

[Qian Yun]

Another one in fricas-lisp.lisp:

Macro |startsId?| |idChar?| are not hygiene, change to function?

- Qian

[Waldek Hebisch]

The first two are OK.

On Wed, Feb 25, 2026 at 05:43:26PM +0800, Qian Yun wrote:
> Another one in fricas-lisp.lisp:
>
> Macro |startsId?| |idChar?| are not hygiene, change to function?

Not sure what you mean, they look fine to me. There is multiple
evaluation of the argument, but Lisp compiler should optimize
this. Even if Lisp compiler could not optimize, performance
loss is less than cost of function call.

--
Waldek Hebisch

[Qian Yun]

Unlike Scheme, Common Lisp macros are not hygiene, the argument
is evaluated multiple times can go wrong if it has side effects.
Aka the macro does not use gensym to prevent it.

Is performance critical for these 2 functions? Otherwise correctness
should come first before performance.

- Qian

[Waldek Hebisch]

The argument should have no side effects, so no trouble due to this.

Concerning "performance critical", this code _should_ be performance
critical. ATM slowness in other parts masks this, but I do not
want to slow down it.

BTW1: Concerning "correctness", at Boot and Lisp level some people
took care in some helper functions to handle "all cases". That
is wrong concern, helper functions should handle all that is
needed and no more (preferably signal errors on unhandled data).
And use should be limited/regular to avoid (if possible)
various special cases. The case you found is a bit different,
but not too much: while we use side effects in arguments when
needed, code which does not use them is clearer, so they should
be discouraged when not strictly needed. And there is a handful
of uses to the involved macros and _none_ of the uses would
benefit from side effects.

BTW2: eventually involved code (that is Spad scanner) is going to be
completely rewritten. Changes make sense when they fix actual
problems, but otherwise I see no need for changes: code is
reasonably clear and works OK.

--
Waldek Hebisch