Re: Make language
Sviđa mi se! -- Kevin R. Bulgrien - Original Message - > From: "Dmitry Goncharov via Bug reports and discussion for GNU make" > > To: "Bartol Hrg" > Cc: bug-make@gnu.org > Sent: Tuesday, October 12, 2021 12:25:05 PM > Subject: Re: Make language > > On Tue, Oct 12, 2021 at 10:38 AM Bartol Hrg > wrote: > > > > Greetings > > > > I installed make 3.81 for Windows > > > > It's in d*mn Croatian! > > > > Now, I don't know if you noticed, but I speak English. > > > > I'm really displeased and agitated. > > > > Best regards > > B. Helium > > Dobar dan. > Vaš pošta je na Engleskom jeziku. > Ne znam jeste li primijetili, ali govorim Hrvatski. > Stvarno sam nezadovoljna i uznemirena. > > Iskreno, Dmitry
Re: Tail call elimination
> I plan to bow out of this discussion as I'm not vested in it, but, a > distinguishing significant functional or interpretive difference > between these two forms is not self-evident: > > 1) > >FILE_SIZES := 5 2 1 4 >TOTAL :- $(math +, $(FILE_SIZES)) > > 2) > > FILE_SIZES := 5 2 1 4 > TOTAL :- $(+ $(FILE_SIZES)) > > In my mind, TOTAL obviously ends up with the same value, but, 1) is > more readable in the same way that almost any language is more > readable than perl with all its non-alpha shortcuts. And I forgot to add that large vocabulary sets can be off-putting (think FORTH which you either HATE or LOVE with little in between). For one, think documentation, and how much easier it would be to edit the existing list of functions and see a list of operators documented in one funcction location. It could be easier to jump to $(math ) in help and see relevant details listed together rather than in separate function definitions $(+ ), $(/ ), $(^ ), $(* ), etc. Of course these could be all in their own "grouping" in the manual, but again, sometimes using existing structures is better when possible, particularly as we tend to know that people kind of love to code new things and not spend as much effort on the documentation. In this case, I do concede, however, that a manual section called "Math", or whatever, could be a good thing if this ever comes to fruition. Oh, and yes, I think simple integer math in make is very intriguing as I routinely use make for implementing recipes that do all sorts of things that presently require shell code to keep thing readable.
Re: Tail call elimination
> There's something to be said for this being able potentially to work > - not that I'm pushing it mind: > FILE_SIZES:= 5 2 1 4 > TOTAL:=$(+ $(FILE_SIZES)) # TOTAL is 5+2+1+4 > Here I'm not objecting to ($math +,$(FILE_SIZES)) or $(op > +,$(FILE_SIZES)) - whatever on them - I am only trying to point out > that we naturally iterate over lists of things in make (e.g. of > targets or filenames) which are space or tab separated and if you > could put a list of numbers into an operation and it just worked it > could be quite neat. It would obviously permit some error cases to > be expressed which could be undesirable e.g. $(/ 1 2 3) could be a > bit ambiguous or at least an unwanted possibility. I plan to bow out of this discussion as I'm not vested in it, but, a distinguishing significant functional or interpretive difference between these two forms is not self-evident: 1) FILE_SIZES := 5 2 1 4 TOTAL :- $(math +, $(FILE_SIZES)) 2) FILE_SIZES := 5 2 1 4 TOTAL :- $(+ $(FILE_SIZES)) In my mind, TOTAL obviously ends up with the same value, but, 1) is more readable in the same way that almost any language is more readable than perl with all its non-alpha shortcuts. If there is a clear difference, then perhaps a more convincing description could be made, but all the "math" comment was doing was to make something a whole lot more clear than "op" (i.e. operand, operator, opportunity, ad nauseum). I'll add that it isn't exactly necessary to create a "new" way of mixing dissimilar arguments (i.e. numbers and operators). Everyone thinks their new idea is better (including me), but it seems that the rest of the world appreciates maintaining order along the lines of the principle of least astonishment. After looking over the list of existing functions (again), I don't think I see one example of a pre-existing function that doesn't use comma when different types of arguments are used. Commas aren't used where all the values are similar... as in $(sort ...), $(words ...), $(lastword ...), etc. I'm not sure what is hard to understand about this being a good thing, and that having an operator in a list of numbers has the potential to create a lot more confusion when looking at the way make works with other functions. Later, and enjoy...
Re: Tail call elimination
> Of course we can still do prefix notation with a single function we > just have to choose a name for it and it's a little less slick; for > example something like: > > $(op + 5 7 $(op * 3 2) 9) > > or whatever so the function is named "op" (for example). Or it could > be named something else like "=", if "= +" doesn't seem too odd. Is "math" a possible function name? Other function syntax where there are "different" types of parameters or arguments (i.e. subst, patsubst, findstring, filter, etc.), use a syntax something like: $(math operator, value list) Consistent syntax patterns are often a plus. ;-)
patch : sco3.2v5.0.7 : 'strlist' redeclared as different kind of symbol
While compiling GNU make 4.1 and 4.2.1 for an old (read ancient) system,
the following problem was encountered:
$ cd /csdi/src/sco507/gnu/make-4.2.1
$ ./configure --prefix=/csdi/src/sco507/root/usr/local
...
$ make
...
gcc -DLOCALEDIR=\"/csdi/src/sco507/root/usr/local/share/locale\"
-DLIBDIR=\"/csdi/src/sco507/root/usr/local/lib\"
-DINCLUDEDIR=\"/csdi/src/sco507/root/usr/local/include\" -DHAVE_CONFIG_H -I.
-I./glob-static -c -o main.o main.c
main.c:98: `strlist' redeclared as different kind of symbol
/usr/include/string.h:67: previous declaration of `strlist'
main.c:98: warning: `strlist' was declared `extern' and later `static'
make[2]: *** [main.o] Error 1
make[2]: Leaving directory `/csdi/src/sco507/gnu/make-4.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/csdi/src/sco507/gnu/make-4.1'
make: *** [all] Error 2
This is resolvable by renaming all strlist in main.c with an alternate
spelling of an identifier. For example:
$ cat make-4.1-i686-pc-sco3.2v5.0.7.patch
diff -ur make-4.1.orig/main.c make-4.1/main.c
--- make-4.1.orig/main.c2014-10-05 11:24:51.0 -0500
+++ make-4.1/main.c 2019-01-10 12:24:05.0 -0600
@@ -95,7 +95,7 @@
flag, /* Turn int flag on. */
flag_off, /* Turn int flag off. */
string, /* One string per invocation. */
-strlist,/* One string per switch. */
+strnglist,/* One string per switch. */
filename, /* A string containing a file name. */
positive_int, /* A positive integer. */
floating, /* A floating-point number (double). */
@@ -119,7 +119,7 @@
#define short_option(c) ((c) <= CHAR_MAX)
/* The structure used to hold the list of strings given
- in command switches of a type that takes strlist arguments. */
+ in command switches of a type that takes strnglist arguments. */
struct stringlist
{
@@ -437,14 +437,14 @@
{ 'W', filename, _files, 0, 0, 0, 0, 0, "what-if" },
/* These are long-style options. */
-{ CHAR_MAX+1, strlist, _flags, 1, 1, 0, "basic", 0, "debug" },
+{ CHAR_MAX+1, strnglist, _flags, 1, 1, 0, "basic", 0, "debug" },
{ CHAR_MAX+2, string, _fds, 1, 1, 0, 0, 0, "jobserver-fds" },
{ CHAR_MAX+3, flag, _flag, 1, 1, 0, 0, 0, "trace" },
{ CHAR_MAX+4, flag, _print_directory_flag, 1, 1, 0, 0, 0,
"no-print-directory" },
{ CHAR_MAX+5, flag, _undefined_variables_flag, 1, 1, 0, 0, 0,
"warn-undefined-variables" },
-{ CHAR_MAX+6, strlist, _strings, 1, 0, 0, 0, 0, "eval" },
+{ CHAR_MAX+6, strnglist, _strings, 1, 0, 0, 0, 0, "eval" },
{ CHAR_MAX+7, string, _mutex, 1, 1, 0, 0, 0, "sync-mutex" },
{ 0, 0, 0, 0, 0, 0, 0, 0, 0 }
};
@@ -2590,7 +2590,7 @@
break;
case string:
-case strlist:
+case strnglist:
case filename:
case positive_int:
case floating:
@@ -2786,7 +2786,7 @@
break;
case string:
-case strlist:
+case strnglist:
case filename:
if (!doit)
break;
@@ -3126,7 +3126,7 @@
break;
case filename:
-case strlist:
+case strnglist:
if (all)
{
struct stringlist *sl = *(struct stringlist **) cs->value_ptr;
The change is small enough, that perhaps someone might consider whether it
is reasonable to make an official change to avoid this name conflict so
future releases do not trigger the same issue. If not, that is fine,
but it would be appreciated.
This is the only source change required to make build on this platform
possible. I realize that this particular platform is far outside of
vendor support, but don't really see the need to go through all that
again, but at least, I figured I'd throw this on the list if only to
archive the finding.
Regards,
Kevin R. Bulgrien
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
