Tim Murphy (29 May 2020 01:02) wrote:
> Integer maths is important at the language level - it will enable
> algorithms that weren't possible before e.g. dividing a list into
> equal halves or a for-loop for which we also need a function that
> generates a range).
Indeed. The only case I can think
On Thu, 2020-05-28 at 17:07 -0500, Pete Dietl wrote:
> Thoughts?
I'm fine with these choices, insofar as I can tell. I reserve the
right to change my mind after seeing the full scope of the proposal :).
On Thu, 28 May 2020 at 22:07, Pete Dietl wrote:
> Upon taking a look at gnulib, I found that they have arithmetic wrap
> functions which guarantee wrapping.
> We can use these functions to guarantee that overflow will just wrap
> around.
>
> Let's leave the shift operators out for now.
>
> comp i
Upon taking a look at gnulib, I found that they have arithmetic wrap
functions which guarantee wrapping.
We can use these functions to guarantee that overflow will just wrap around.
Let's leave the shift operators out for now.
comp is for complement. ~
In most scheme implementations, providing o
On Thu, 2020-05-28 at 22:07 +0200, Jouke Witteveen wrote:
> Here is a thought: The current support for numeric variables is
> limited to unsigned numbers. We could choose to stick with that!
I'm not sure how this would work... it works today because we have no
subtraction and all numbers make can
On Wed, 2020-05-27 at 13:47 -0500, Pete Dietl wrote:
> Technically, the C standard allows for machines which don't use 2's
> complement. So should we consider our LONG_MIN to be -2^63 + 1?
>
> Also, signed arithmetic overflow is undefined behavior, so should we
> also indicate that we have undefi
On Wed, May 27, 2020 at 8:47 PM Pete Dietl wrote:
>
> A few questions.
>
> Technically, the C standard allows for machines which don't use 2's
> complement.
> So should we consider our LONG_MIN to be -2^63 + 1?
>
> Also, signed arithmetic overflow is undefined behavior, so should we also
> indica
Any suggestions or comments?
On Wed, May 27, 2020 at 1:47 PM Pete Dietl wrote:
>
> A few questions.
>
> Technically, the C standard allows for machines which don't use 2's
> complement.
> So should we consider our LONG_MIN to be -2^63 + 1?
>
> Also, signed arithmetic overflow is undefined behavi
A few questions.
Technically, the C standard allows for machines which don't use 2's complement.
So should we consider our LONG_MIN to be -2^63 + 1?
Also, signed arithmetic overflow is undefined behavior, so should we also
indicate that we have undefined behavior or should we use some
function th
On Mon, 2020-05-25 at 15:44 -0500, Pete Dietl wrote:
> As for converting between bases, that could always be a separate
> function like `$(convert-base number,radix)` where radix is one of:
> 2, 8, 10, or 16
I agree it should be a separate function.
Perhaps it would be better to consider a more g
> This really annoys me and keeps me on the fence about gnulib, and
> prevents me from completely switching (for example, moving to modern
> glob/fnmatch). I've only pulled in some relatively simple elements so
> far.
>
> So... I'm not sure which way to fall on that.
Apparently gnulib requires
>
> I believe the form being considered is:
>
> $(math OPERATOR,LIST)
I am still partial to `$(math ...)`
with only one argument.
> The only one I'm not sure about is overflow. That will need some
> thought. Gnulib contains a comprehensive set of macros to deal with
> overflow, in various ways.
On Mon, 2020-05-25 at 13:28 -0500, Pete Dietl wrote:
> Question about 64-bit, what happens when compiling make for a 32-bit
> system? I don’t think c90 has `stdint.h`... maybe there’s something
> in gnulib. Anyway, would we want to support 64 bit integers even on
> 32-bit platforms?
32bit platform
On Mon, 2020-05-25 at 12:07 -0400, Sam Kendall wrote:
> I'd like to raise some questions that I think any proposal ought to
> answer. I'll assume a straw man proposal: there's one function, and
> it takes one of the following forms:
>
> $(math OPERATOR,VALUE1,VALUE2)
> $(math OPERATOR,VALUE1)
I b
`long long` was not introduced until c99, neither was `stdint.h`, but
perhaps gnulib can help us out here.
On Mon, May 25, 2020 at 3:44 PM Pete Dietl wrote:
>
> > I was not even considering specifying the base of the the resulting
> > expansion. I was assuming it would always be base 10. I don'
> I was not even considering specifying the base of the the resulting
> expansion. I was assuming it would always be base 10. I don't have
> any good way to specify the output form.
>
> I was only considering the parsing of input (constant) values: whether
> we wanted to support 0xfff, 0o777, 0b1
On Mon, 2020-05-25 at 10:10 +, Edward Welbourne wrote:
> > > Mult-base support: should we support only base 10 integer
> > > constants in
> > > expressions, or also hex/octal constants?
> > I vote for decimal, hex, and binary.
> > Octal if you really want it.
>
> A case for octal and bitwise a
On Mon, 25 May 2020 at 18:34, Pete Dietl wrote:
> Question about 64-bit, what happens when compiling make for a 32-bit
> system? I don’t think c90 has `stdint.h`... maybe there’s something in
> gnulib. Anyway, would we want to support 64 bit integers even on 32-bit
> platforms?
>
> If at all poss
Question about 64-bit, what happens when compiling make for a 32-bit
system? I don’t think c90 has `stdint.h`... maybe there’s something in
gnulib. Anyway, would we want to support 64 bit integers even on 32-bit
platforms?
Sam Kendall (25 May 2020 18:07) observed:
> If you have relational or equality operators, what does the boolean
> result look like? If the result is 1 for true and 0 for false, then
> you get a bad surprise: $(if $(math =,5,6),yes) expands to yes. If the
> answer is some nonempty string for true an
I'd like to raise some questions that I think any proposal ought to answer.
I'll assume a straw man proposal: there's one function, and it takes one of
the following forms:
$(math OPERATOR,VALUE1,VALUE2)
$(math OPERATOR,VALUE1)
A binary operator (first form) is one of + - * and /. The only unary
Pete Dietl (22 May 2020 09:18)
> As for a name for $(cond), we could call it
> $(alu ...)
> And put arithmetic and logical operations in it :)
Amusing as this is, I don't think it's a good name !
> I don’t like using $(cond)
> Because because I sort of want to option to implement cond like in Sch
>>> Bit Manipulation:
>>> --
>>> * and
>>> * or
>>> * xor
>>> * complement
>>> * left shift
>>> * right shift
>>
>> Maybe. I have a hard time coming up with uses for these, other than
>> possibly the shift operators (but multiplication/division can be used
>> instead).
Pete Di
On Sun, 2020-05-24 at 14:09 -0500, Pete Dietl wrote:
> > I think, as I mentioned before, that someone (I guess that's you
> > :)) should write up an actual proposal (maybe, for example, the
> > start of a new manual section) that can be examined and commented
> > on.
>
> Challenge accepted! What i
> I think, as I mentioned before, that someone (I guess that's you :))
> should write up an actual proposal (maybe, for example, the start of a
> new manual section) that can be examined and commented on. Endless
> streams of mailing list responses quickly give diminishing returns. My
> experienc
On Sat, 2020-05-23 at 15:43 -0500, Pete Dietl wrote:
> > I understand what Tim is saying but I still prefer to have a single
> > function. I want to reduce the "namespace leakage" for these
> > capabilities. If we decide to add more operations to this in the
> > future I don't want it colliding w
> I understand what Tim is saying but I still prefer to have a single
> function. I want to reduce the "namespace leakage" for these
> capabilities. If we decide to add more operations to this in the
> future I don't want it colliding with something else we want to do.
>
> However, sometimes it's
On Fri, 2020-05-22 at 23:14 -0500, Pete Dietl wrote:
> So we are back to debating between many functions or (one or two)
> functions. Anyone else care to weigh in?
I understand what Tim is saying but I still prefer to have a single
function. I want to reduce the "namespace leakage" for these
capa
So we are back to debating between many functions or (one or two)
functions. Anyone else care to weigh in?
I don't fully understand these motivations, which is again not to say they
are not good - I just don't get them:
1) to implement everything in 1 function (or 2) - it seems like a slightly
artificial requirement - one that a user of the feature wouldn't think to
ask for.
2) documentation - again, pr
As for a name for $(cond), we could call it
$(alu ...)
And put arithmetic and logical operations in it :)
I don’t like using $(cond)
Because because I sort of want to option to implement cond like in Scheme.
> 5 + (2 * 9 / (7 + 5 + 4)) * (1024 * 1024) / 19
>
> becomes:
>
> $(math +, 5 $(math /, $(math *, $(math /, $(math *, 2 9) $(math +, 7 5 4))
> $(math *, 1024 1024)) 19))
>
> versus:
>
> $(op + 5 $(op / $(op * $(op / $(op * 2 9) $(op + 7 5 4)) $(op * 1024 1024))
> 19))
>
> or:
>
> $(+ 5 $(
On Thu, 2020-05-21 at 11:46 -0400, Paul Smith wrote:
> In my discussion of the way to handle conditions I even mentioned
> allowing just one operand which would give the identity function.
>
> After sleeping on it, though, I'm not sure if that's the best idea.
> Maybe we should assume "0" for a m
On Thu, 2020-05-21 at 11:22 -0500, Kevin R. Bulgrien wrote:
>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
> 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
> 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 po
On Thu, 2020-05-21 at 15:35 +, Tim Murphy wrote:
> 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
> +,$
On Thu, 21 May 2020 at 13:08, Paul Smith wrote:
>
> > 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 a
On Thu, 2020-05-21 at 00:37 -0500, Kevin R. Bulgrien wrote:
> > 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 f
> 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
On Wed, 2020-05-20 at 19:56 -0500, Pete Dietl wrote:
> Paul when you get a chance, could you let me know what you think
> about using many prefix functions?
I'm not sure. I may need to see the proposal to get a feel for what it
really means.
Of course we can still do prefix notation with a singl
Paul when you get a chance, could you let me know what you think about
using many prefix functions?
> Both a Lisp-like prefix syntax and a Forth/RPN-like postfix syntax are
> concise and easy to implement. Infix semantics are messy, because they
> require special "order of operations" logic to resolve ambiguities, and
> there is no universal standard for that.
Oh I completely agree.
I think tha
On Wed, 20 May 2020, Paul Smith wrote:
Grouping: do we try to implement expression grouping with () (e.g.,
$(expr (1 + 1) * 4) or is it good enough to just say people need to
nest expr functions: $(expr $(expr 1 + 1) * 4)?
I think nesting `expr` is too noisy.
We need to find a good balance b
> No, I don't agree with that. Trying to change the base make parser
> like that would be a major source of issues.
Yeah that is what I surmised.
> > > Grouping: do we try to implement expression grouping with () (e.g.,
> > > $(expr (1 + 1) * 4) or is it good enough to just say people need to
>
On Wed, 2020-05-20 at 17:17 +, Tim Murphy wrote:
> So if guile is a good language which does math in postfix notation
> (+ 1 1)
You mean prefix notation :)
I do have fond memories of postfix notation from my HP calculator but
it wouldn't work for GNU make.
> then I don't see why make can't b
On Wed, 2020-05-20 at 11:48 -0500, Pete Dietl wrote:
> Another option would be to introduce some new syntax like $(()),
> but that might break existing Makefiles and would probably be more
> work, though it looks cleaner IMO.
No, I don't agree with that. Trying to change the base make parser
like
On Wed, 20 May 2020 at 15:47, Daniel Herring wrote:
> Hi Pete,
>
> My objections to GMP:
>
> - major added dependency (Make needs to be widely portable, and it is
> often part of a boot-strapping procedure. The core functionality needs to
> be trim. Heavy lifting needs to be separable.)
>
> - s
On Tue, May 19, 2020 at 11:13 AM Paul Smith wrote:
>
> No, I don't like this. Perhaps addition is sufficient for your use-
> case but others may need multiplication or division and I certainly
> don't want to start adding 10 different explicit funtions like "add",
> "mult", etc. I prefer a singl
On Wed, 2020-05-20 at 11:13 -0500, Pete Dietl wrote:
> > - major added dependency (Make needs to be widely portable, and it
> > is often part of a boot-strapping procedure. The core
> > functionality needs to be trim. Heavy lifting needs to be
> > separable.)
>
> The shared library for libgmp do
> If anyone can provide any use case where >64bit math is needed in a
> makefile I'll be interested to hear about it.
Yeah fair enough :)
Then we can always build in support since the size addition to the
Make binary will be trivially changed.
> > * negate
> > * absolute value
> > * exponentiate
> - major added dependency (Make needs to be widely portable, and it is
> often part of a boot-strapping procedure. The core functionality needs to
> be trim. Heavy lifting needs to be separable.)
The shared library for libgmp does not have dependencies on anything besides
libc, so libgmp only a
On Wed, 2020-05-20 at 10:34 -0500, Pete Dietl wrote:
> I really like the idea of using GMP to do the math.
No, I'm not willing to make that requirement.
If anyone can provide any use case where >64bit math is needed in a
makefile I'll be interested to hear about it.
But, my position is that if y
Hi Pete,
My objections to GMP:
- major added dependency (Make needs to be widely portable, and it is
often part of a boot-strapping procedure. The core functionality needs to
be trim. Heavy lifting needs to be separable.)
- slow (native int32 is much faster)
- massive YAGNI (Make is a bui
I really like the idea of using GMP to do the math.
Does it make sense to restrict ourselves to integer only? Probably,
but just a thought. Could always introduce it later.
Yes there is the question of use case and YAGNI, but there's also the
case of why artificially restrict the abilities of $(exp
On Tue, 2020-05-19 at 15:21 +0100, Tim Murphy wrote:
> A question would be do we want to use GMP or are 64 bit ints enough?
> I'm inclined to say ints are ok of they are wide.
Straight 64bit integer arithmetic is fine IMO. I'm definitely not
interested in adding another library dependency.
> So
A question would be do we want to use GMP or are 64 bit ints enough? I'm
inclined to say ints are ok of they are wide.
Sorry to jump to such a basic question. I sort of think it helps frame a
discussion about what people really want.
I mostly needed addition, comparison and decrement of values th
On Mon, 2020-05-18 at 21:40 -0400, Daniel Herring wrote:
> This decision causes a difficult and error-prone ambiguity when the
> return value is really true and empty. For example, the operation
> succeeded and the result was "", versus the operation failed and thus
> returned "". So Scheme added
On Mon, 18 May 2020, Paul Smith wrote:
This is also an objection against $(eq) and $(not), which are hidden
behind the EXPERIMENTAL compilation flag.
It doesn't matter what the output is, IMO. Boolean expressions in GNU
make are quite trivial: empty string is false, anything else is true.
So
On Mon, 2020-05-18 at 16:01 -0500, Pete Dietl wrote:
> I concur that string handling and comparison should be considered in
> a separate discussion.
>
> So let’s consider just integer comparison and arithmetic here?
The usual method is someone makes a concrete proposal (say, something
on the same
I concur that string handling and comparison should be considered in a
separate discussion.
So let’s consider just integer comparison and arithmetic here?
On Mon, 2020-05-18 at 20:04 +, Tim Murphy wrote:
> Re comparing strings: we already have ifeq and what I have often
> wanted is to have a function equivalent so I can use it in
> expressions. As bad as ifeq may be from the point of view of locale
> this need be no better to be an improvement ov
Re comparing strings: we already have ifeq and what I have often wanted is
to have a function equivalent so I can use it in expressions. As bad as
ifeq may be from the point of view of locale this need be no better to be
an improvement over the unpleasant hacks I've had to use to get the same
effec
On Mon, 2020-05-18 at 21:05 +0200, Jouke Witteveen wrote:
> Otherwise, POSIX prescribes an expr command, so with:
> expr = $(shell expr '$1')
> you can already do $(call expr,2 * 3 + 5).
Please remember not every user of GNU make has access to a POSIX
environment.
I'm not suggesting we re-impleme
On Mon, 2020-05-18 at 21:05 +0200, Jouke Witteveen wrote:
> On Mon, May 18, 2020 at 8:50 PM Paul Smith wrote:
> >
> > On Mon, 2020-05-11 at 16:32 -0500, Pete Dietl wrote:
> > > I would like to know your thoughts about adding something like
> > > $(expr
> > > ) to evaluate integer expressions and
$(shell) causes severe parse performance problems in large makefiles unless
you use it extremely sparingly.
[insert strong expression of frustration at make's deficiencies being
treated as blessed] :-)
Regards,
Tim
On Mon, 18 May 2020 at 19:18, Pete Dietl wrote:
> > Each of these has an ob
Also, I think an advantage of an $(expr) command is that we can have
it return an empty string on false,
whereas with shell we have to transform the output conditionally based
on whether we are performing arithmetic
or comparison...
Speaking of
> return value of a call to $(shell) is available in $(.SHELLSTATUS).
I think it would be a nice addition to have some global setting where
any failed $(shell )
command automatically fails Make.
> Each of these has an obvious 'output', which is not the case for
> something like a comparison operator. This is also an objection
> against $(eq) and $(not), which are hidden behind the EXPERIMENTAL
> compilation flag.
I think the convection is that an empty string is false while a
non-empty st
On Mon, May 18, 2020 at 8:50 PM Paul Smith wrote:
>
> On Mon, 2020-05-11 at 16:32 -0500, Pete Dietl wrote:
> > I would like to know your thoughts about adding something like $(expr
> > ) to evaluate integer expressions and comparisons.
>
> I have no problem with some basic math facilities. We alr
Yes
On Mon, 2020-05-11 at 16:32 -0500, Pete Dietl wrote:
> I would like to know your thoughts about adding something like $(expr
> ) to evaluate integer expressions and comparisons.
I have no problem with some basic math facilities. We already have
functions like $(word ...), $(words ...), and $(word
Yeah I was thinking something like:
VERSION := 1.3.0
OLD_VERSION := 1.2.0
EMPTY :=
SPACE := $(EMPTY) $(EMPTY)
ver_is_less_than = $(strip \
$(let \
( \
(major1 $(word 1,$(subst .,$(SPACE),$1))) \
(minor1 $(word 2, ...)) ... \
) \
$(if $(expr
I have often wanted to auto generate targets with progressive numbers to
ensure uniqueness or count the number of times a particular macro is used
and most especially to compare two numbers to see if they are numerically
greater, less or equal.
Example: generating rules from potentially very long
> It should not be necessary for the use-cases of make
I assert that arithmetic functionality does have use-cases in Make.
Beyond building, I use Make for packaging my software and running tests.
I often find that it would be useful to perform version comparisons
and other simple packaging things.
On Mon, May 11, 2020 at 11:33 PM Pete Dietl wrote:
>
> Indeed I understand these concerns.
> So the consensus seems to be that I may go ahead and attempt to implement
> this.
>
> Other than the (let) and tail call optimization, I would like to know your
> thoughts about
> adding something like $
Daniel Herring (11 May 2020 21:46) wrote, inter alia,
> For example, when a code generator like Qt's moc or uic is run, it
> could also generate a rule update that causes Make to compile and link
> the results.
For reference, Qt6's moc (the Qt project's current dev branch) supports
dependency gene
And I swear that's the last thing I want. :)
Indeed I understand these concerns.
So the consensus seems to be that I may go ahead and attempt to implement
this.
Other than the (let) and tail call optimization, I would like to know
your thoughts about
adding something like $(expr ) to evaluate integer expressions and
comparisons.
On Mon, 2020-05-11 at 14:01 -0500, Pete Dietl wrote:
> What do you all think about me attempting to implementing tail call
> elimination for recursive make functions? This combined with the
> proposed (let) construct would be rather powerful.
If it's straightforward it doesn
y (communicate simple Make rules).
>
> If we do want Make to be Turing-complete, then it may be better to link in
> an embedded language (Guile, Lua, Python, ...), rather than building a new
> ad-hoc language.
>
> - Daniel
>
>
> On Mon, 11 May 2020, Pete Dietl wrote:
>
Make rules).
If we do want Make to be Turing-complete, then it may be better to link in
an embedded language (Guile, Lua, Python, ...), rather than building a new
ad-hoc language.
- Daniel
On Mon, 11 May 2020, Pete Dietl wrote:
What do you all think about me attempting to implementing
What do you all think about me attempting to implementing tail call
elimination for recursive make functions? This combined with the proposed
(let) construct would be rather powerful.
I did the first 10 exercises in Advent of Code 2019 in Make. but ran into
problems with blowing the stack from
83 matches
Mail list logo
