|
|
|
|
|
|
by pron
3191 days ago
|
|
|
> Abstract types are existentially quantified Oh, you mean something like this? interface A<T> {
T x();
void y(T t);
}
void foo(List<A<?>> as) { // every element may have a different instance of T
for (A<?> a : as)
bar(a);
}
<T> void bar(A<T> a) {
T t = a.x();
a.y(t);
}
> There are no runtime type errors at all in Standard ML.There are no runtime type errors at all in TCL, either. That doesn't mean that the language is safer. "Safety" and "type safety" are not the same. Type safety has its virtues, but I would argue that Java's type safety is good enough; I would take it along with its dynamic capabilities over SML for many projects -- it's just a tradeoff that buys you a lot of other stuff. There's a price you pay for dynamic runtime capabilities and for deep cross-language interop (e.g. a Clojure list is a Java List), and that's a price worth paying in many cases, considering that it's not high at all. > This is what happens when engineers design programming languages. I guess engineers prioritize things based on what they're actually worth to developers (or, at least, according to how much they believe they're worth to their developers) as opposed to using an arbitrary metric for some intrinsic quality, whose relationship with actual benefit isn't at all clear. Java sacrifices a tiny bit of type safety for interop and various dynamic capabilities. I wasn't aware that there's been some major discovery showing that this is the wrong tradeoff to make. |
|
|
Kind of, but, with wildcards, you still don't get the ability to unpack the existential for arbitrary further use. You can only unpack the existential within a single method, which is unnecessarily restrictive. If you unpack the same existential package twice (say, because you need to do it in two different methods, neither of which calls the other), then, as far as the type checker cares, that produces two different abstract types. Programming with abstract types in Java is a pain, which is why (understandably) Java programmers don't do it.
> There are no runtime type errors at all in TCL, either.
Yeah, but you don't get basic things such as integers, which is even worse.
> There's a price you pay for dynamic runtime capabilities and for deep cross-language interop (e.g. a Clojure list is a Java List)
Anyhow, the only thing I wouldn't want to do in Standard ML is manipulate arrays, mainly because runtime bounds-checking is unnecessary when you get your array algorithms right, but Standard ML requires it anyway. Interoperability between two memory-safe languages is completely useless to me.
> and that's a price worth paying in many cases, considering that it's not high at all.
Any price is high when you get nothing in exchange for it.