See something in this issue you'd like to comment on? Heard some exciting news you'd like to share? Saw a typo you'd like us to ignore and pretend it was a feature? You can a) write about it on the dozens of social media websites out there, or b) be one of the cool kids and email us your comment and we might include it in our next issue's Reader Mail: [email protected]
Basically a type-interpretation for function-blocks
In our last issue, Martin Savage introduced one of his language's (QED) core ideas: type function equivalence (TFE). In this issue, Martin returns (no pun intended) to expand on these concepts but before that, let's check out one of the interesting comments in this Reddit thread. User htuhola writes
So you have described a type-interpretation for function-blocks. The interpretation is opened when function is prefixed with "new", also their names populate type-namespaces? Eg. 'string' could be represented as some function if you demote it from being a builtin type.
Overloading of language constructs seem to be something that'll be coming to languages eventually, but they differ from your presentation a bit. Check up Conal Elliot's "compiling to categories" -presentation.
When you abstract something, ideally it'd make sense to work with the abstract objects and abstractly defined things would make sense in different contexts. Eg. id(a) : a → a makes sense for every value of a. Does string() have some useful interpretation as a function?
Martin responds: As absurd as it seems... yes. I have one common namespace for both types and functions, although I see it more as a function namespace. In my stdlib, along declarations such as println(...), there is string(), int()... Void is not inside, as it just means the absence of a return value. If I run it today, the program would suspend indefinitely, so it is not really useful. A bit like intentionally dividing by 0. The reason for suspension is hinted in my article about coroutines, which showcases type/function equivalence on the domain of concurrency..
Further further reading
In another Reddit thread, u/devops1011 recommends "Type Theory and Formal Proof: An Introduction" by Nederpetl and Guevers if you liked James Philips' article "There's a Mathematician In Your Compiler".
Basically the slicing problem
And finally, many people in this other Reddit thread concluded that the unexpected bug that Jonathan Boccara was talking about in "Polymorphism and the Ternary Operator: Trickier Than You Think" is essentially the slicing problem documented here and here in the C++ Language Standard which states
Otherwise, if the second and third operand have different types and either has (possibly cv-qualified) class type, or [...], an attempt is made to form an implicit conversion sequence from each of those operands to the type of the other. [...] if exactly one conversion sequence can be formed, that conversion is applied to the chosen operand and the converted operand is used in place of the original operand for the remainder of this subclause.
The second and third operands have the same type; the result is of that type and the result object is initialized using the selected operand.