10 ms·
I have a pet language, in which `f.g(x)` is merely syntax sugar over `{typename of f}_g(f, x)`. It's a combination of two ideas - the colon operator for method
by mappu 11y ago
I have a pet language, in which `f.g(x)` is merely syntax sugar over `{typename of f}_g(f, x)`. It's a combination of two ideas - the colon operator for method calls in lua, and extension methods from C# &c.
I think this debate is a small part of a larger one about unified namespaces, and for functions in particular. There's no good reason for a named function to coexist with a like-named function variable. Javascript gets this a right by having `function f` largely equivalent to `var f = function`.
I'm impressed that C++ continues to evolve 37 years later. It's a stark contrast to, say, the Go 1 Compatibility Promise.
- marvy 11y agoC++ tries to make the same guarantees that the Go 1 compatibility promise makes. (Or at least very similar; they are different languages after all.) Basically: old code should keep working possible, but they have the right to invent new features. The real difference is that C++ is feature-philic (new feature: want!), while Go is feature-phobic (new feature: avoid!) Of course, if you want to make specific predictions about which features C++ or Go will adapt, then you need to look at details. For instance, Stroustrup tried hard in the early days to ensure that user-defined types are on equal footing with built-in types, while Go tried hard in the early days to make sure that very common foundational types are built in and have good support. Thus today the C++ standard library has two at least two distinct dictionary types, while Go has one built in to the language. (Someone who actually knows more about Go history than I do, please correct me if I'm wrong.) I tend to favor the C++ approach as more mathematically pleasing, but I can't deny that the Go approach leads to a simpler language. (The real question is: which one leads to better programs, and I suspect the answer is "it depends, on way too much stuff to even list".)
- deleted 11y ago[deleted]
- blub 11y agoThere are several dictionary types in C++, but each has different performance characteristics and they all have good support. Thanks to the efforts to make built-in types and UDTs equal, Qt's map was for instance implemented as a skip list and was just as usable as the standard library types. Nowadays it's a RB Tree. Go's strategy of picking hash maps and not offering the mechanisms of building your own data structures with the same syntax affordances and performance characteristics makes it easy to jump in and hard to make progress if you hit a wall with the built-ins.
- marvy 11y agoYep. I guess they're counting on that being so rare that it's worth paying the price in occasionally having to rewrite (and uglify) large chunks of code, in exchange for having a simpler language.
- Ono-Sendai 11y agoIn my language f.g(x) is syntactic sugar for g(f, x). Prefixing with the typename of f is not needed due to function overloading. (Which basically does the same thing I guess)
- mappu 11y agoInteresting! Do you have separate symbol tables for functions and variables, then? I've taken the major design decision that there's only one symbol table for variables, so every function is a functor. I'm not sure it's possible to reconcile this with function overloading (Go/Javascript don't) EDIT: i suppose you could have a different symbol table for each variable type, incorporating function arities.
- Ono-Sendai 11y agoI don't really use symbol tables in the compiler. But with function overloading, binding needs to be done by name and type, yes. It does complicate the binding process significantly.