Re: Tail call elimination

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

Re: Tail call elimination

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

math expressions (was: Re: Tail call elimination)

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

Re: Tail call elimination

> - 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

Re: math expressions (was: Re: Tail call elimination)

> 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

Re: Tail call elimination

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

Re: Tail call elimination

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

Re: Tail call elimination

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

Re: Tail call elimination

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

Re: Tail call elimination

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

Re: Tail call elimination

> 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 >

Re: Tail call elimination

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

Re: Tail call elimination

> 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

[bug #58420] PATH changes are not applied in $(shell) function

URL: Summary: PATH changes are not applied in $(shell) function Project: make Submitted by: srivasta Submitted on: Wed 20 May 2020 06:21:52 PM CDT Severity: 3 - Normal I

[bug #58420] PATH changes are not applied in $(shell) function

Follow-up Comment #1, bug #58420 (project make): I stand corrected. The actual CC should be 895835-forwar...@bugs.debian.org ___ Reply to this item at: _

Re: Tail call elimination

Paul when you get a chance, could you let me know what you think about using many prefix functions?

[bug #58420] PATH changes are not applied in $(shell) function

Follow-up Comment #2, bug #58420 (project make): $(shell) commands in a recipe... well, we've all seen it done. But, hang on, PATH doesn't behave specially for me: martind@sirius:~/tmp/make-58420$ cat Makefile NOT_PATH := /nonexistent:$(NOT_PATH) $(shell echo during parsing NOT_PATH=$(NOT_PAT

Re: Tail call elimination

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

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