[jonathanstrange]

Pragmas are always a bad idea. The Ada community has learned that the hard way. Whatever the pragma does, it should be part of the language standard and never be implementation-dependent.

It's time that language designers include language pragmatics in the core language. That includes for example big O information about data structures, packing of structures, alignment properties, memory access information, etc. Currently, in most if not all languages this information is spread all over levels, from nonstandardized compiler flags over pragmas up to the core language. It's a huge mess.

[masklinn]

> Pragmas are always a bad idea. The Ada community has learned that the hard way. Whatever the pragma does, it should be part of the language standard and never be implementation-dependent.

> It's time that language designers include language pragmatics in the core language. That includes for example big O information about data structures, packing of structures, alignment properties, memory access information, etc.

So pragmas are "always a bad idea" but you should have them "in the core language"… Don't you feel your comment is pretty contradictory?

A pragma is a directive for the system (mostly compiler), that's orthogonal to it being implementation-specific.

[jonathanstrange]

You misread my comment. The functionality offered by pragmas must be mandatory and in the core language, whether you call them pragmas or not. Everything else leads to problems.

It's true that if pragmas were all fully specified in the core language and not optional, then they wouldn't pose any problems. In reality, however, some pragmas are regulated by the core language and others are implementation specific additions. The result is a huge mess, it's the #1 source of incompatibility of standardized languages like Ada. Even just having optional pragmas in the core language is problematic, because at one point or another developers will start relying on the optional functionality to do something that one implementation does and another doesn't. Optional optimization and packing directives are typical examples. In theory they shouldn't be able to break programs, in reality they do.

[masklinn]

> You misread my comment. The functionality offered by pragmas must be mandatory and in the core language, whether you call them pragmas or not. Everything else leads to problems.

Your previous comment literally states that pragmas are always bad, then goes on to state that they should be included in the core language. This one does not retract the original statement that pragmas are "always a bad idea" but further asserts pragmas "must be mandatory and in the core language".

I don't think I misread your comment, no. You may have miswritten your comment when you meant that, say pragmas should not be optional and/or implementation dependent[0], but that's on you.

[0] I've no idea whether that's you mean given again you state that pragmas should both not exist and be part of the core language.

[jonathanstrange]

When I said "pragmas are always a bad idea" I was talking about pragmas as they are implemented in current languages like e.g. Ada. In most languages pragmas are added to the language without being integrated into it. For example, in Ada you write "pragma (Something);" next to other statements to influence their interpretation by the compiler. Other languages have similar mechanisms that are somehow outside the core language or added on top of it. These types of pragmas are always a bad idea.

I also argued that the functionality of pragmas must be represented as non-optional choices in the core languages. This is one of the lessons that the Ada community has learned over time - but it's too late to change this now in Ada.

So yes, pragmas are always a bad idea if we talk about the way they are implemented in most languages. The functionality of pragmas should be part of the core language, with proper syntax and semantics.

I hope that clarifies what I've stated and which you haven't understood, and that, your nitpicking aside, my position now makes sense to you. If not, there is not much I can do, I just wanted to point out a lesson learned in the Ada community, which is very stringent about language definitions. If you're interested in these kind of topics, I can recommend Michael Scott's Programming Language Pragmatics.

[kemitche]

I don't know if I agree. The pragmas listed in the article, by and large, are directives at specific parts of the reference go implementation, allowing for specific optimizations/annotations that implementation needs. Any other implementation of go seems like it could safely ignore those directives.