Live data from Hacker News

Why we're supporting Typed Clojure

blog.circleci.com

61–70 of 77 posts

Re: Why we're supporting Typed Clojure

#61
post #46

Earlier quoted context omitted.

Yep that's correct. I want a tool that infers a rough approximation of top-levels to accelerate the process of porting untyped code to be typed. The programmer would inspect the annotations manually and fix any inaccurate ones, and then run the type checker.

I'm far from an expert on this, but F# has no requirement for all forms to be explicitly typed, so I'm a bit puzzled as to why this is hard.

I believe it has to do with features like subtyping and method overloading which cause havok for global type inference. Found a paper here: http://ropas.snu.ac.kr/lib/dock/HoMi1995.ps

Re: Why we're supporting Typed Clojure

#63
post #42

Earlier quoted context omitted.

A compiler designed to support things like code completion can have an explicit API. For example, it may be asked to parse the code until the cursor location, the do a longjmp back out (or throw an exception, or whatever) with symbolic information about that location in the code. If the parser error recovery is decent (and there is some effort put into this in most substantial front ends, since it's key to good error…

That might work...but does it work in practice (i.e. do you have an example where this is being used?). I've found that most IDEs support two kinds of compilers: the compiler used to generate code and find type errors, and a "presentation" compiler to provide interactive feedback that is error tolerant and can run in incomplete contexts. Java works this way, Scala worked this way (at least when I was working on the p…

See: http://www.skybert.net/emacs/java. With Java, Emacs can just talk to the Eclipse Java Compiler, since it exposes an API. Same thing with Clang--it exposes an API which is used by XCode to support interactive feedback, and Emacs can consume it too. The Open Dylan compiler was originally intended to interface tightly with the Open Dylan Windows IDE, and that interface has been repurposed to interface with Emacs.

Re: Why we're supporting Typed Clojure

#64
This guy is a little too souped on optional type-checking. This has existed in erlang for years, in the form of dialyzer (which allows for compile time validation of complex nested data structures), and in any dynamic language a good developer is using pre-checks & post-checks (in the case of js) or a combination of tagged values and pattern matching to ensure type-checking at runtime.

It's a nice feature, but calling it "one of the biggest advancements to dynamic programming languages in the last few decades" is ignorant.

Re: Why we're supporting Typed Clojure

#65
post #63

Earlier quoted context omitted.

That might work...but does it work in practice (i.e. do you have an example where this is being used?). I've found that most IDEs support two kinds of compilers: the compiler used to generate code and find type errors, and a "presentation" compiler to provide interactive feedback that is error tolerant and can run in incomplete contexts. Java works this way, Scala worked this way (at least when I was working on the p…

See: http://www.skybert.net/emacs/java . With Java, Emacs can just talk to the Eclipse Java Compiler, since it exposes an API. Same thing with Clang--it exposes an API which is used by XCode to support interactive feedback, and Emacs can consume it too. The Open Dylan compiler was originally intended to interface tightly with the Open Dylan Windows IDE, and that interface has been repurposed to interface with Emacs.

Cool, are these APIs buffer based or area based? I mean, when you make a change, do you get the message: the buffer has changed, or is there an area-based damage-repair cycle as in Eclipse or Visual Studio?

Re: Why we're supporting Typed Clojure

#66

There is already typing in Clojure (and Python and Ruby). It`s called "100% unit test coverage". If you want it, you can have it now.

Coverage isn't the same as enumeration of all possible modes. 100% test coverage might mean that all of your "wiring" fits together, but with dynamic languages it may not as runtime information may affect your types and break things.

100% enumeration of runtime behaviors is another property, far stronger than any non-dependent static types today, but also exponentially more difficult than 100% test coverage.

Good static types are a cheap way to get probably halfway between those two on a log scale.

Re: Why we're supporting Typed Clojure

#67
post #55

Earlier quoted context omitted.

That's insane.

For a very long time I've regarded Racket as a purely educational Scheme dialect not particularly useful for real work. It was only a few months ago that I actually bothered to look at it's ( amazing! ) documentation [1] and realized how wrong I've been. It's incredible what are the Racket guys doing and what they've already achieved. The Typed Racket [2, 3] is "only" a cherry on top. [1] http://docs.racket-lang.org/…

What I see is that in part the transition from MZscheme to Racket has meant that a new generation of Lisp oriented academics are in PLT leadership roles - this is something Felleisen has long promoted in his own work (e.g. listing junior authors first on joint papers since everyone already knows who he is).

In other words, Racket is now being driven by research into computation and the earlier generation's area of emphasis - the pedagogy of computation - is being treated as a largely solved problem. This is not to say that PLT is no longer pursuing pedagogical projects or that in the past there wasn't significant discovery and invention within computation, only that the How to Design Programs project offers a mature and battle tested framework for teaching introductory programming and there is not a lot of reason to revisit it.

One of the things that attracts me to Racket - beyond the fact that it is a Lisp - is that the documentation is full stack. I was aware of the paper because there is a link within the Racket documentation of the contract system. The payoff from reading a paper that is specifically organized around the language at hand is intellectual continuity and when the language is a Lisp that continuity extends all the way from implementation to the lambda calculus.

Re: Why we're supporting Typed Clojure

#68
post #2

The paper behind Racket's new contract system which allows optional typing to be determined at runtime or compile time or both and across modules: http://www.eecs.northwestern.edu/~robby/pubs/papers/oopsla20...

That's insane.

I suspect it is done with higher order functions in a manner analogous to what Rich Hickey has done with map and reduce here:

http://www.infoq.com/presentations/Clojure-Reducers

Re: Why we're supporting Typed Clojure

#69
post #42

Earlier quoted context omitted.

A compiler designed to support things like code completion can have an explicit API. For example, it may be asked to parse the code until the cursor location, the do a longjmp back out (or throw an exception, or whatever) with symbolic information about that location in the code. If the parser error recovery is decent (and there is some effort put into this in most substantial front ends, since it's key to good error…

That might work...but does it work in practice (i.e. do you have an example where this is being used?). I've found that most IDEs support two kinds of compilers: the compiler used to generate code and find type errors, and a "presentation" compiler to provide interactive feedback that is error tolerant and can run in incomplete contexts. Java works this way, Scala worked this way (at least when I was working on the p…

That might work...but does it work in practice (i.e. do you have an example where this is being used?).

It is how the Delphi compiler works in the IDE. I used to work for Borland, then Embarcadero, on the compiler front end.

When the compiler is running for code completion (kibitz mode, it calls it), it does a lot less work. No codegen, no type analysis of function bodies (begin / end blocks are entirely skipped), unless the cursor location is discovered to be inside a function body, whereupon the it rewinds and does more complete analysis. Normally takes no more than a few milliseconds to finish.

Re: Why we're supporting Typed Clojure

#70
post #47

This is great news for Clojure. Based on my experience, dynamic languages without optional typing make large scale enterprise development unbearable. Sure, one should be writing unit tests, but in the enterprise context those tests rarely do exist, or if they do, either don't test what they should or are so complex that invalidate any re-factoring taking place.

Do you have any experience with the inverse statement? That is, have you had a good experience with optional types in an enterprise context?

I'm curious how many runtime errors persist due to the optionality of the type system. Perhaps code standards requiring all "library" code to be typed would be a good balance.

Post reply on HN