ambrosebs

Most of the research that Typed Clojure is based on didn't even exist when Clojure was created. Rich just made the best language he could, and waited for type theory to catch up, as it were!

See this goldmine of papers for Typed Racket http://www.ccs.neu.edu/home/samth/

Cool!

It's invaluable with abstract code that throws around functions. It's also fantastic for documenting your code.

Watch "Typed Clojure" 2012 Conj talk, might reveal more about where it's best suited.

Just as cool though! :)

Thanks.

There are certainly important tradeoffs. Haskell the language and Haskell the type system are designed to prevent many kinds of programming mistakes.

Typed Clojure is designed to follow any decisions Clojure makes. For example, it's not a type error to lookup a nonexistent key in a map, so we can't really catch typos in keys. Clojure allows dynamic code loading, so it would be rather fruitless to try completeness checking (and languages like Haskell can do it so much better).

You might want to watch my 2012 Clojure Conj talk. I think it touches briefly on this issue. I've always tried to be upfront about the limitations of Typed Clojure.

I apologise if that was a bit rambly, it's 5AM :)

Fantastic, bring it on!

No problem, just was eager to clarify :)

FWIW there are macros like fn> that allow you to write (fn> :- Number [a :- Symbol] 1), but you lose the ability to write ordered function types with multiple cases, so I don't use it very much.

May I suggest stealing some of core.typed's syntax for your docstrings, especially for polymorphic functions?

It scales very well, from simple types like clojure.core/symbol:

https://github.com/clojure/core.typed/blob/57da1175037dfd61c...

to polymorphic types like clojure.core/repeat:

https://github.com/clojure/core.typed/blob/57da1175037dfd61c...

to succinct representations of complicated polymorphic types like clojure.core/fnil

https://github.com/clojure/core.typed/blob/57da1175037dfd61c...

and I'll spare you the really insane annotations.

Of course you can pick and choose what's to your liking.

Here's a brief tutorial on type syntax: https://github.com/clojure/core.typed/wiki/Types

core.typed author here.

It might be easy to consider Schema as "competitor" to core.typed. In fact, it's the opposite: once they play nicely together they will form a formidable bug-fighting, finely-documenting team. :)

core.typed has accurate compile time checking, and Schema gives an expressive contracts interface for runtime checking.

Once they understand each other, you can start pushing and pulling between static and dynamic checking by using both libraries to their strengths.

Currently, core.typed requires all vars have top level annotations. This is partly because there is no way to recover type information once inside a function body. However, if we have an entire namespace using Schema liberally, we can use schemas to recover information!

This means we can lean on schemas for most annotations, and rely on core.typed to catch arity mismatches, bad arguments to clojure.core functions, potential null-pointer exceptions and many more nasties at compile time.

Then you might start adding static annotations or removing schemas, depending on the kind of code your dealing with. You might do some "static" debugging to ask whether a schema is needed to prevent a type error. core.typed would also let you know when your contracts are insufficient to rule out type errors. Really, you're free to use both tools as you'd like.

Schema looks very nice, thanks for open sourcing it Prismatic folks!

Just so readers don't deduce you're talking about core.typed, core.typed is plenty expressive enough to represent many idiomatic Clojure data structures, and very succinctly.

eg. Heterogeneous keyword maps https://github.com/frenchy64/core.typed-example/blob/master/...

core.typed will have to be extended to understand schemas. core.typed already plays nicely with assertions and branches (via occurrence typing), so we just need information on what type a schema "casts" to. This will not be difficult, it might not even have to live in core.typed's implementation and be extended via multimethods.

One of the problems with gradually annotating an untyped namespace with core.typed is we immediately have to be very accurate with our type annotations.

However if the namespace is completely "schema'ed", we can assume functions simply take `Any` as arguments and rely on Schema to regain type information.

This could be a very nice way to work.

Author of core.typed here.

I will challenge that schemas are "significantly" better for documentation than core.typed types.

With unions, intersections, heterogeneous maps, parameterised classes, recursive types we can be very expressive.

Here's some examples of the syntax for types: https://github.com/clojure/core.typed/wiki/Types

And some declarative types in action: https://github.com/frenchy64/core.typed-example/blob/master/...

I think core.typed is restrictive enough to allow annotations like the one above, while being opinionated enough to guide the programmer to write clear, comprehensible types.

Typed Clojure multimethod support is work in progress, but closing in.

Shen is pretty amazing and is built with a type system in mind from the beginning. If you don't want the type system, just turn it off, in the middle of a REPL session if you want!

I'll just note that any corrections are more than welcome, this is my first paper and I've got a lot to learn! Please send them to abonnairesergeant at gmail dot com.

Thanks, I intentionally chose examples where types are particularly useful, like monads and conduits (and apparently null elimination).

Multimethods are an awesome feature, which I'm a big fan of, but they were lower on my priority list so I haven't got around to typing them. It's not clear how comprehensively they can be typed either, I comment about it in "Future work".

I don't know a lot about type-classes, but I'm doubtful that Typed Clojure could help make protocols like them. I would expect a whole different dispatch system would need to be designed. But that's mostly a hunch. Very interesting problem.

If you want to play around with this kind of stuff immediately, check out Typed Racket. The Typed Clojure implementation is in alpha and might not be very friendly yet :) That said, please try it out!

Thanks for a very exciting and productive year with your work on core.logic. Can't wait to see how it gets used in the future!

... and I'll be around, so ditto! (I'm Ambrose)

Lisps make it fairly difficult to reason about resource consumption based on code size. And in general, is not a good metric for such a measurement.

FWIW I would pronounce it "delete all".