On Wed, Mar 11, 2020 at 12:23 AM Levieux Michel <[email protected]> wrote > It seems you missed something here. "Please like my proposal or everyone loses" is not an argument.
No one has debated the power, importance and virtues of my proposal. Apparently you didn't read the comments in the proposal. The discussion is about why they can't be bothered. Maybe enough likes would motivate a discussion of the merits instead of perceived risks that apparently can't be solved by a good developer. On Wed, Feb 19, 2020 at 9:17 AM Robert Griesemer <[email protected]> wrote: > An integrated compile-time language makes a compiler essentially programmable; > there's no question that this would be very powerful. This comment is from the proposal. Not one person has disagreed with "very powerful". If you disagree, please say why? How is this not far more powerful than GO GENERATE, pre-processors and macro's? Why isn't a very powerful feature important to everyone? Shouldn't the compiler developers spend more than 5 minutes consideration on very powerful features before they dismiss them? Isn't this proposal worth a "like" just to consider if it's possible? This proposal is failing because of fear that we will repeat the mistakes of the past. Great developer's will ask how a powerful feature can be made safe in their product instead of finding excuses not to consider it. "liking" a proposal doesn't mean it will be implemented. Instead, it tells developer's it's important to you and try to find a way to implement that feature. On Wed, Feb 19, 2020 at 9:17 AM Robert Griesemer <[email protected]> wrote: > It's unclear to me how flexible an approach you are envisioning. My vision doesn't matter. This must be a team vision. I have a lot of experience with this so I know what works and what fails. I know how to address many of the fears mentioned. On Tue, Feb 25, 2020 at 2:57 PM Ian Lance Taylor <[email protected]> wrote: > This proposal is incomplete Robert put the proposal best: make GO programmable at compile time. Everything else in the proposal demonstrates possibilities and justifies the value of the proposal. Anything beyond this is a waste of my time at this point. > I made a similar proposal at #32620 <https://github.com/golang/go/issues/32620>, hygienic macros Not similar and this should not be allowed. The only part of the AST affected would be the #xxx( xxx ) which would be replaced with the generated code. > turing complete These issues have been addressed in other compilers. These issues can be addressed. > because they slow down the compile times, Compile time is not affected if #xxx( xxx ) is not used in the code. Does GO GENERATE or pre-processors save compile time by reading the source twice? Are they able to produce results as a programmable GO? > do not follow the simplicity and design goals of Go Why is this impossible to be part of the requirements? > Choose a compile time language. Possibly GO, Python, Java, NodeJS or??),which is a bad idea for a variety of reasons. I'm not saying user's have a choice. I'm saying this is a decision to be made during requirements or design phase. > What this proposal describes is a language that is very different from Go. If the language chosen is GO, then it's not different. It could be a brand new minimal language that is similar to GO. This is a decision to be discussed. > It's even more unlikely that that language would be one as powerful Why would you want a powerful language at compile time. You're not reading files, using goroutines or most other functionality used at run time. > It looks like what you want is something like constexpr in C++. Constexpr is useless for solving complex problems at compile time (e.g. gettext). It's amazing how a poorly designed feature get's abused because the language does not meet our needs. > the args can't be evaluated at compile time At compile time, everything is a constant. The compiler breaks down #xxx( yyy ) as constants into AST's. When #xxx is called, the AST's are made available to the function as ARGS. > I used make and awk programs that generate assembly code tuned > to the exact demands of command line make configuration. Then it builds in go, then runs. I want consistency for everyone, available with GO and easy to use. I'm sure this worked for you but compile time does not need to be complex. Simplicity is your friend. Thanks, Jon. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAByJhJn584h2AM_kRr8eZaGShfu-FjKxgBwCWpL-Cq11t79svQ%40mail.gmail.com.
