Earlier quoted context omitted.
Indeed. I'm hoping the IDE support will include emacs - it can already do loads of cool things connected to nrepl, but completion on a hash would be amazing.
Does emacs support language aware intelliense (auto complete) for any language? I thought the common case was support through CTAGs.
Why we're supporting Typed Clojure
51–60 of 77 posts
Re: Why we're supporting Typed Clojure
#52People interested in optional types for Python may be interested in my @typ decorator that implements them: https://github.com/cabalamat/ulib/blob/master/debugdec.md Sample: @typ((int,float), ret=(int,float)) def square(x): return x*x Here the parameter x is an int or float, and so is the return type. It doesn't currently let you compose types, but that wouldn't be too difficult to add, e.g. {str:int} could mean a di…
That's okay, but that doesn't seem to help much to verify your type correctness before runtime, which seems to me to be a big part of the benefit of type checking. Also, what you'd really want is something that implements type variables like:
@typ[A implements *](A, ret=A)
def square(x):
return x * x
BTW, your printargs looks pretty cool! I might just makes something like that for JS...
Re: Why we're supporting Typed Clojure
#53There 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.
Can 100% unit test coverage give you intellisense, real-time warnings, and refactoring capabilities? Nope.
Unit testing is great for verifying that a piece of code works conforms to specification, but typing verifies that you're using a piece of code as expected. Two different things.
Re: Why we're supporting Typed Clojure
#54Earlier quoted context omitted.
Indeed. I'm hoping the IDE support will include emacs - it can already do loads of cool things connected to nrepl, but completion on a hash would be amazing.
Does emacs support language aware intelliense (auto complete) for any language? I thought the common case was support through CTAGs.
Yes, you can make it work for at least Java (JDE, I think?) and Python (I forget the mode, it's to do with Pymacs).
Re: Why we're supporting Typed Clojure
#55The 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.
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/
[2] The Type Racket Guide: http://docs.racket-lang.org/ts-guide/
[3] The Type Racket Reference: http://docs.racket-lang.org/ts-reference/
Re: Why we're supporting Typed Clojure
#56There one thing that really stirred my interest:
nil isn’t allowed
If this really is what I think it is (a certain reference to a class can never be nil) then I am really excited. It never made sense to me that someone was able to call a function I wrote that really needed instances with nils instead, so I was forced to check and throw in case they did. It's just not clear and it leads to a lot of unnecessary checking or nil pointer exceptions.
Re: Why we're supporting Typed Clojure
#57> Typed Clojure is one of the biggest advancements to dynamic programming languages in the last few decades. It shows that you can have the amazing flexibility of a dynamic language, while providing lightweight, optional typing. I'm sure there have been great advances. But you are showcasing this as if it was a completely new idea, even though PHP has been using it for a long time. Correct me if I'm wrong.
OP here. This is substantially different than what exists in PHP. I tried to hint about this when referencing "nominal" vs "structural" in the piece, but you can just about say "I expect the parameter to be this type" in PHP, which is substantially less powerful than this.
Gradual typing is not as radical, however, as a fully type inferred language, see:
http://research.microsoft.com/apps/pubs/default.aspx?id=1961...
I think we can go much farther in this area than we have with Hindley Milner. Of course, this is still research, but as long as you are claiming "biggest advance in the last few decades" I might as well just throw this out there.
Re: Why we're supporting Typed Clojure
#58> Typed Clojure is one of the biggest advancements to dynamic programming languages in the last few decades. It shows that you can have the amazing flexibility of a dynamic language, while providing lightweight, optional typing. I'm sure there have been great advances. But you are showcasing this as if it was a completely new idea, even though PHP has been using it for a long time. Correct me if I'm wrong.
On this note, this doesn't seem to be more powerful than CL:s optional typing, am I wrong?
Re: Why we're supporting Typed Clojure
#59An introduction to typed clojure (strangely missing from both the blog post and the IndieGoGo campaign):
Re: Why we're supporting Typed Clojure
#60There one thing that really stirred my interest: nil isn’t allowed If this really is what I think it is (a certain reference to a class can never be nil) then I am really excited. It never made sense to me that someone was able to call a function I wrote that really needed instances with nils instead, so I was forced to check and throw in case they did. It's just not clear and it leads to a lot of unnecessary checkin…
nil is explicit in Typed Clojure, and it's a goal to statically avoid misuses of nil.
This rough screencast describes on aspect to the approach http://vimeo.com/55280915