Previous Entry Share Next Entry
Features to come: Strong Typing
jducoeur wrote in querki_project
It occurs to me that I've talked a lot about Querki's flexibility, and those who have played with it so far know that the type system doesn't really come into play beyond slight suggestions. This may be giving folks the impression that Querki is always going to be as loosely typed as Javascript or Ruby. Digging into Haskell a bit this past weekend reminded me that I should set expectations appropriately.

For now, Querki is largely untyped, and its type system is always going to be a little weird. But in the medium term, the plan is for it to become more and more strongly typed. Frankly, I think that's necessary in order to make the user experience better: a completely untyped environment forces you to catch most of the bugs at runtime, which sucks both for the naive and experienced users.

We'll hopefully begin to get the type system in play by late this year. The first step will be adding a proper concept of function signatures. The internal functions will state what their signatures are. I'm honestly not sure whether user-level code will ever need to do so: in principle, we *should* be able to infer the signatures of most user functions based on what they do, and ideally we should infer all of them. We'll see if that proves feasible or not.

To make these signatures work properly, we will probably not only need a more robust notion of Type, we'll also likely want a notion akin to Haskell or Scala's typeclasses: meta-types that are defined as essentially "all Types that have versions of these function signatures". (Typeclasses aren't a super-high priority, but they make more advanced programming far easier. And quite frankly, having a Numeric typeclass may prove just plain necessary in order to keep the various numeric Types consistent.) To this, we'll likely add a sort of strong duck-typing: functions that simply rely on the existence of specific Properties will effectively declare that as a de facto typeclass. We'll need some way to extend a Type with new functions from the "outside", so that mix-in Apps can extend Types with additional functionality.

The final step will likely be the Querki equivalent of a compiler. QL is currently 100% interpreted, in the most old-fashioned way, but that's a poor long-term plan for all the usual reasons. So we will move towards fully parsing and interpreting all QL expressions when you save them. If those expressions don't "compile" properly -- in particular, if the typechecking indicates that they can't ever work right -- we will show an error indicating what has failed and why. We will almost certainly allow you to save uncompilable expressions (there are many workflow reasons to allow this), but we'll try to indicate problems much more quickly than we do today. We will probably actually save the expressions in both "source" and "object" forms, which should speed up runtime considerably.

Note that, while all of this is needed, as little as possible of it is going to be very user-visible. Folks sometimes think of type systems as excessively complex, and when they are in your face they often can be. But a complex type system mostly lives at the library/system level, and the entire point is to allow user-level code to DWIM better: to tell you quickly and precisely when and why your code won't work, and to make it easier to fix it.

Questions, thoughts and opinions are welcomed. None of this is set in stone, and none of it is going to happen really soon. But hopefully all of it will come in the next year...
Tags: ,


Log in

No account? Create an account