[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more m4sugar tweaks
Re: more m4sugar tweaks
Fri, 22 Aug 2008 08:33:56 -0600
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20080708 Thunderbird/220.127.116.11 Mnenhy/0.7.5.666
-----BEGIN PGP SIGNED MESSAGE-----
According to Ralf Wildenhues on 8/22/2008 8:02 AM:
>> This meant the user could modify the definition of variable
>> to skip or replay iterations, potentially even entering an infinite loop.
>> ~ The new implementation ignores user changes to variable, always
>> performing as many iterations as was determined up front.
> That's ok. However, do we provide for a method that allows a for-like
> loop which allows to mess with the iteration variable while looping?
Not currently; the user would have to write the recursion themselves.
> Asking because that may allow for a "break"-like construct. I'm not
> asking you to implement this if we don't have it yet (a TODO item would
> be fine), but if we do, hinting at it in the manual would be nice. It
> is not a problem if this method is slower than m4_for.
I'm adding this as a TODO item (it doesn't bother me enough to try
implementing it now). Other thoughts - maybe provide m4_break, which
normally is an error, but when executed inside this new loop macro, will
gracefully stop iteration. Or provide something like m4_while(TEST, EXPR)
which evaluates EXPR repeatedly until TEST expands to the empty string
(hopefully EXPR modifies whatever TEST will expand to).
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
>From 0b8af134157753edec45bb9f78795596b1fcd07a Mon Sep 17 00:00:00 2001
From: Eric Blake <address@hidden>
Date: Fri, 22 Aug 2008 08:31:03 -0600
Subject: [PATCH] * TODO: Add an item for additional m4sugar looping constructs.
Suggested by Ralf Wildenhues.
Signed-off-by: Eric Blake <address@hidden>
ChangeLog | 3 +++
TODO | 13 +++++++++++--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 6a642cd..9a90bde 100644
@@ -1,5 +1,8 @@
2008-08-22 Eric Blake <address@hidden>
+ * TODO: Add an item for additional m4sugar looping constructs.
+ Suggested by Ralf Wildenhues.
Add reminder to keep dual implementations in sync.
* lib/m4sugar/m4sugar.m4: Add comments.
* lib/m4sugar/foreach.m4: Likewise.
diff --git a/TODO b/TODO
index 368268c..f85ba54 100644
@@ -228,6 +228,15 @@ this for translators.
F**k! --trace FOO does not catch indir([FOO], $@)!
Fixed in M4 1.6, but we can't rely on it yet.
+** m4 loops
+As of 2.63, m4_for has a fixed iteration count for speed in the common
+usage case. But it used to allow the user to alter iteration count by
+reassigning the iterator, allowing a break-like functionality (or even
+infloops). Does this need a new (but maybe slower) macro? Should we
+also provide something like m4_while([TEST], [EXPR])? Maybe an
+m4_break() that works inside a looping construct?
* Autoconf 3
** Cache name spaces.
@@ -246,7 +255,7 @@ should depend upon the current language.
I think one sad decision in Autoconf was to use white space separated
lists for some arguments. For instance AC_CHECK_FUNCS(foo bar). I
tend to think that, even if it is not as nice, we should use m4 lists,
-i.e., AC_CHECK_FUNCS((foo, bar)) in this case. This would ease
+i.e., AC_CHECK_FUNCS([foo, bar]) in this case. This would ease
specializing loops, and more importantly, make them much more robust.
A typical example of things that can be performed if we use m4 lists
@@ -255,7 +264,7 @@ a space in their names, eg, structures.
With the current scheme it would be extremely difficult to loop over
AC_CHECK_STRUCTS(struct foo struct bar), while it natural and well
-defined for m4 lists: AC_CHECK_STRUCTS((struct foo, struct bar)).
+defined for m4 lists: AC_CHECK_STRUCTS([struct foo, struct bar]).
I know that makes a huge difference in syntax, but a major release
should be ready to settle a new world. We *can* provide helping tools