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.
Why we're supporting Typed Clojure
61–70 of 77 posts
Re: Why we're supporting Typed Clojure
#62NB. And I believe Perl6 in certain cases will/can raise compile-time type errors.
Re: Why we're supporting Typed Clojure
#63Earlier 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…
Re: Why we're supporting Typed Clojure
#64It'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
#65Earlier 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.
Re: Why we're supporting Typed Clojure
#66There 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.
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
#67Earlier 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/…
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
#68The 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.
Re: Why we're supporting Typed Clojure
#69Earlier 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…
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
#70This 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.
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.