4 ms·

That's still a bunch of magic that C++ and Java don't really get to use though, isn't it? Or would you consider this to be on the same level of adding opcodes

That's still a bunch of magic that C++ and Java don't really get to use though, isn't it? Or would you consider this to be on the same level of adding opcodes to the JVM?

usrusr 8y ago
Sure, the desugaring is special treatment, compiler "magic" that is not available at all to other libraries that might like to similarly hook into the map syntax. I was just trying to explain how this does not have to conflict with the claim that the map implementation (the runtime library functions that are called by the desugared version) is plain, regular Go. You could rewrite the map implementation, you just would not get the nice syntax. Compared to Java, it's somewhere in the middle between the regular, entirely "un-magic" implementation of maps and the deeply built in nature of the array primitive, which is not only special at compile time (like Go maps) but also at runtime.
jerf 8y ago
I'd consider it fairly similar to the distinction between Java and the JVM, yes, in that the JVM technically has more power than the Java language exposes. There's multiple levels, with different powers. You're not going to be able to draw a sharp line here where Go is somehow on one side of it and most other languages aren't. In a sense the entire point of a "language" in the first place is to provide various bits of "magic" to make your life easier. For instance, you can't implement your own exceptions system, because the compiler hooks in at a deeper level than you can get to. (In both cases you can probably do it via what are technically platform-specific hacks, but I wouldn't say that you've implemented it in the language.) The only language with "no magic" is pure assembler, with either no macros or at least no predefined macros.
- pjmlp 8y ago
  Actually even Assembly has magic if the CPU is microcoded.

4 ms·

That's still a bunch of magic that C++ and Java don't really get to use though, isn't it? Or would you consider this to be on the same level of adding opcodes

by royjacobs 8y ago

That's still a bunch of magic that C++ and Java don't really get to use though, isn't it? Or would you consider this to be on the same level of adding opcodes to the JVM?

usrusr 8y ago
Sure, the desugaring is special treatment, compiler "magic" that is not available at all to other libraries that might like to similarly hook into the map syntax. I was just trying to explain how this does not have to conflict with the claim that the map implementation (the runtime library functions that are called by the desugared version) is plain, regular Go. You could rewrite the map implementation, you just would not get the nice syntax. Compared to Java, it's somewhere in the middle between the regular, entirely "un-magic" implementation of maps and the deeply built in nature of the array primitive, which is not only special at compile time (like Go maps) but also at runtime.
jerf 8y ago
I'd consider it fairly similar to the distinction between Java and the JVM, yes, in that the JVM technically has more power than the Java language exposes. There's multiple levels, with different powers. You're not going to be able to draw a sharp line here where Go is somehow on one side of it and most other languages aren't. In a sense the entire point of a "language" in the first place is to provide various bits of "magic" to make your life easier. For instance, you can't implement your own exceptions system, because the compiler hooks in at a deeper level than you can get to. (In both cases you can probably do it via what are technically platform-specific hacks, but I wouldn't say that you've implemented it in the language.) The only language with "no magic" is pure assembler, with either no macros or at least no predefined macros.
- pjmlp 8y ago
  Actually even Assembly has magic if the CPU is microcoded.