findinglisp wrote:Maybe I'm not following you, but why do you care about typing? From your original posting, it sounds like you just need it for documentation purposes, to communicate with users of your API. If that's true, then I'd suggest that you just use well-written doc strings and be done with it.
Exolon wrote:Hi, have you looked at Qi? It has a static typing system (and has some nice features like pattern matching).
tlareywi wrote:It is true that this serves as a sort of documentation. However, it goes beyond that because documentation isn't part of the runtime system. A person may or may not read the documentation. Even if they do, they may still pass something unintended into the package that doesn't generate problems immediately but rather down the road during runtime at some point, making it difficult for them to determine a root cause. The motivation for typing interface points between packages is so that you can make some solid statement, enforced by the system, regarding what you define as valid input. If the interfaces are open to any input then you've effectively created a situation where you must anticipate any possible input a user of your package may provide. By typing your interfaces, you're not letting them pass in things that you don't anticipate and hence increase your code's robustness. Granted, this doesn't always matter but it does sometimes.
(defun foo (bar)
(unless (integerp bar)
(error "BAR must be an integer"))
As a little background, I come from mainly a C++/COM environment building large applications. So some of my ideas I'm sure carry over from that. However, for the past year I've worked mainly with Lua, an interactive scripting language with functional features and dynamic typing (I've been learning Lisp in hopes that I could get the best of both worlds, and then some). A significant percentage of defects we've encountered in this code base arises from developers calling interface points, where the arguments are of dynamic type, with an unpredicted 'type' of argument. There are plenty of cases where the documentation is read but not well understood.
Anyway, I really hope I don't spawn a type system war (pointless) as that isn't my intention at all. There's a place for many different kinds of type systems. I just wish they'd bend to my will
findinglisp wrote:So, I'm still not sure what you are after, exactly:
- API enforcement
- Performance optimization
So I still don't see the benefit. In a C++/COM world, type mismatches cause big problems because operations are not type-checked. In Lisp, you can't accidentally add a string and an integer. When you try, you'll generate a condition and be dropped into the debugger. At that point you typically have a full stack trace and can quickly identify where things went wrong.
If it was such a big problem, you'd see it being done in Lisp code all over the place, and that just isn't the case.
I'm not hung up on type systems, so you aren't offending me at all. I'd simply suggest that if you really want to learn Lisp, that you try to not impose your C++/COM background on it.
Users browsing this forum: Google [Bot] and 1 guest